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The Adaptive Architectures for Command and Control (A2C2) project is a research 
effort sponsored by the Office of Naval Research to explore adaptation in joint command 
and control structures. The project’s second experiment builds on the first experiment and 
studies the interaction between task structure and organizational structure. This thesis 
builds on the work of previous theses by Michael Berigan and Greg Higgins. It describes 
a process for developing military operational scenarios within a task structure context. 
First, the author conducts a literature review, which defines the dimensions of task 
structure applicable to this project, and describes how changes in one dimension might 
affect other dimensions. Then a method for developing scenarios in accordance with a 
predetermined structure and visualizing tasks is described, including a task structure 
diagram and a description of a task design process using the diagram and the dimensions 
previously delineated. The author then applies the task design process by developing two 
scenarios for the second NPS A2C2 experiment that differ across one dimension of task 
structure, coordination requirements. Finally, a description of the experiment is given, 
including discussion of operationalization of scenarios and organization structures, and 
lessons learned from the experiment with regard to scenario design. 
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EXECUTIVE SUMMARY 



The Adaptive Architectures for Command and Control (A2C2) project is a four-year 
research effort sponsored by the Office of Naval Research. It involves researchers at the 
Naval Postgraduate School (NPS), the University of Connecticut, Michigan State 
University, George Mason University, Alphatech Inc., Aptima Inc., and several other 
institutions. The research focuses on organizational adaptation in joint command and 
control organizations, exploring how, why, and when organizations adapt or should adapt 
their structures, what skills, training, and technology are required to support that 
adaptation, and developing computer aids to help custom design organization structures 
for specific missions. The project consists of field research, computer modeling, and a 
series of human-in-the-loop experiments. 

The A2C2 project uses a multi-player real-time simulation environment capable of : 

• Focusing on the dynamic execution of the combatant phases of the mission 

• Allowing researchers to easily manipulate key task structure variables and 
available resources and organizational structures. 

The approach taken combines analytical and empirical efforts to develop a model- 
test-model paradigm of experimentation with human teams. A first step in this process 
was to abstract "real world" problems in order to bring them into a controlled laboratory 
environment where we could control a large variety of experimental conditions while 
manipulating independent variables of interest in order to measure their effects on the 
dependent variable used to test the hypotheses of interest. 

The first experiment, conducted at NPS in March 1996, served as a baseline and test- 
run of the DDD-EH simulation. The second experiment built on the findings of the first to 
explore the interaction between task structure and organizational structure and drivers of 
adaptation in an organization. This thesis focuses on the objectives of the A2C2 project in 
general and the specific details of the second NPS experiment conducted 12-26 
November 1996. Emphasis is on the resources, scenario, and tasks designed to support 
the experiment and hypotheses selected by the A2C2 research team. 

To design the scenario for the second NPS A2C2 experiment, a visual representation 
of a task’s structure was developed using the task structure diagram methodology 
developed by Michael Berigan in NPS experiment one. 

A literature review which defines the dimensions of task structure applicable to this 
project (uncertainty, time pressure, complexity, coordination requirements, magnitude, 
resources required, information required, task formalization, and dynamicity) and 
describes the task structure diagram is provided in the second chapter. 

Once the dimensions of task structure are defined and a grading scale developed, an 
explanation of a task structure diagram is given. Many dimensions of task structure are 
represented directly in this diagram; others can be inferred from it. The task structure 
diagram method allows experimenters to ensure a task accomplishes the objectives that 
have been set, provides a straightforward, visual method for comparing it with other 
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tasks, and describes a task to those outside the task design process. 

The task design process is then used to describe the second NPS A2C2 experiment. 
The dimension of interest was determined by the definitions of dimensions of task 
structure given previously, initial A2C2 field research, and results from the first NPS 
A2C2 experiment. The task structure dimension of interest, coordination requirements, 
was selected as the independent variable and introduced at two levels: high internal 
coordination and high external coordination over shared resources. The scenario used for 
A2C2 field research and the first NPS experiment provides the foundation for the second 
experiment. The next step is to design the scenario tasks, develop an organizational 
structure and provide data to UCONN modelers as input to their model-based optimized 
organizational structure. 

Designing the experiment, required resolution of several issues: 

• How to measure performance of organizations in order to compare their 
performance when using different organizational structures to perform the same 
tasks. Two task structures were used to examine whether interactions between 
task and organizational structures exists. 

• How to inject internal and external stimuli, that were essentially equivalent in 
terms of the task load to resource ratio, into the scenario to induce adaptation in 
the organizations. An internal stimuli is a change to resources or capabilities of 
the organization. An external stimuli is a change in the environment or mission. 

Of interest in the second experiment, with regard to organizational structure, were the 
performance of the model-based and operational organization structures and the designs 
of those dynamically selected by the subjects during the planning sessions. This interest 
results in the following research questions: 

1. Does the performance of the model-based design organization match the model’s 
predictions of performance? 

2. In the face of an internal “ trigger ”, do teams adapt by changing architectures? 

3. In the face of an external “ trigger ”, do teams adapt by changing architecture? 

4. Do organizations adapt their organizational structures based on changes in mission 
task and resources available? 

5. Why and how do organizations adapt? 

6. Are some organizations better able to accommodate changes to mission or 
resources without a drop in performance than others? Are some organizations more 
robust than others? If so, why? 

7. Can the model-based organizational structures developed by the modelers at 
UCONN, based on task structure and available resources, perform as well or better than 
those developed using the current method of selecting organizational structures used by 
operational commanders, as measured by performance, resources utilization, mission 
accomplishment, and losses? 

Finally, a description of the experiment, including setup, discussion of 
operationalization of the scenarios and organizational structures, training conducted with 
the subjects, conduct of the experiment itself, and lessons learned from the experiment 
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with regard to scenario design is provided. A brief overview of the preliminary findings 
from the data, summary of the thesis and future areas of research complete the paper. 



I. INTRODUCTION 



A. THE A2C2 PROGRAM 

The Adaptive Architectures for Command and Control (A2C2) Project is a 
continuing effort to examine adaption in joint command and control organizations. Rapid 
advances in communications technology and computers have made real-time command 
and control (C2) possible. This revolution in C2 capability will soon provide decision 
makers (DMs) in a joint military organization with an unparalleled tactical and strategic 
picture of the battlefield. A current area of focus within the Department of Defense (DoD) 
is organization of the force. New, highly evolved organizational concepts are considered 
one of the “enablers of the revolution in military affairs” (Joint War fighting Center, 
1995). The Joint Staff’s C4I for the Warrior (C41PTW) concept, Copernicus, Sea Dragon, 
and other service initiatives that reside within the overarching C4IFTW concept call for 
flattened command structures. These flattened command structures will allow U.S. forces 
to begin achieving more efficient use of enhanced sensor-to-shooter communications 
capabilities and dominant battle space knowledge. Decision makers (DMs) will have the 
ability to rapidly access all information available within the organization, monitor actions 
made by other DMs, and call upon a world-wide data base to aid in the combat decision 
process. This powerful, “omnipotent” capability has been dubbed “Global 
Awareness”(Joint War fighting Center, 1995). 

Researchers at the Naval Postgraduate School, the University of Connecticut, 
George Mason University, Michigan State University, Alphatech Inc., and Aptima Inc. 
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have theorized that the most capable organizations will respond by adapting their 
structures and processes from traditional, rigid hierarchical organizational structures into 
more flexible, network-like architectures to take advantage of the opportunities presented 
by enhanced sensor-to-shooter communications capabilities and dominant battle space 
knowledge. 

Current research involving adaptive architectures for joint C2 seeks to examine 
the interactions between mission requirements and organizational structure. The Office 
of Naval Research (ONR), in the summer of 1995, commissioned a four-year research 
effort into this far-reaching topic - the A2C2 project. This project is exploring the 
changes in task structure, mission, and resources that drive changes to organizational 
structure in the joint warfare environment, and how the joint organization should adapt. 

The A2C2 project is a national joint effort by researchers from academia, 
(University of Connecticut (UCONN), George Mason University(GMU), Michigan State 
University (MSU)), government agencies (Naval Postgraduate School, (NPS)), industry 
research activities (Alphatech Inc., Aptima Inc.), and other institutions. The project’s 
goals are to advance the state of knowledge regarding decision making performance in 
joint organizational settings, to better understand how, why, and when organizations 
adapt or should adapt to a changing environment, and if the changes result in improved 
organization performance, to develop the skills, training, and technology required to 
support that adaptation (Alphatech/UCONN/NPS, 1995, p. 2). The researchers will make 
use of organizational theory, organizational models, simulated combat experiments with 
military officers, and field observation with experienced operational commanders in an 
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iterative process to expand this body of knowledge. The A2C2 project is moving through 
several phases. In late 1995, the data collection process began with field research, visits to 
military organizations, participation in demonstrations and wargames, and a round of 
structured interviews with experienced commanders from all branches of the U.S. Armed 
Forces. 

The purpose of the field research was to identify potential drivers of adaptation in 
joint operations, from the perspective of commanders experienced in joint operations, and 
to raise the specific issues that should be addressed in the project’s later experiments. 
“Drivers of adaption” is a phrase used to describe changes in mission tasks, resources, 
technology, etc. that cause an organization to adjust its structure or functionality for 
improved performance. 

After the field interviews, the A2C2 researchers began a series of experiments 
using war games and simulations of increasing complexity and fidelity. Each experiment 
builds upon the field research, insights gained from modeling, and previous experiments. 

The approach taken combines analytical and empirical efforts in a model— test- 
model paradigm featuring experimentation with human teams. A first step in this process 
was to abstract "real world" problems in order to bring them into a controlled laboratory 
environment where a large variety of experimental conditions could be controlled while 
manipulating independent variables of interest in order to measure their effects on the 
dependent variable used to test the hypotheses of interest. In order to conduct the 
empirical research, the A2C2 project requires a multi-player real-time simulation 
environment capable of : 



3 



• Focusing on the dynamic execution of the combatant phases of the mission 

• Allowing researchers to easily manipulate key task structure variables and 
available resources and organizational structures. 

The Distributed Dynamic Decisionmaking (DDD-III) paradigm was used as the 
simulation environment for both the first and second NPS experiments. This third- 
generation simulation is an evolution of an earlier version developed by UCONN 
(DDD-II), which was used extensively to conduct empirical research from 1989 - 1995 
involving "open-ocean" naval team (distributed) decisionmaking and coordination. 
(Higgins, 1996) 

B. PURPOSE OF THE THESIS 

This thesis will discuss the objectives of the A2C2 project in general and the 
specific details of the second NPS experiment conducted 12 - 26 November 1996. 
Emphasis is on the resources, scenario, and tasks designed to support the experimental 
design, goals, and hypotheses. 

To make this thesis a stand-alone document, several chapters from Michael 
Berigan’s thesis, which focused on the first A2C2 experiment, will be included to provide 
background information. 
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c. 



THESIS OUTLINE 



This paper consists of seven chapters and two appendices. 

• Chapter II is an overview and review of those portions of Michael 
Berigan’s thesis on the first NPS experiment which are applicable to this 
paper. 

• Chapter EH develops the methodology used to design the scenario and 
provide the inputs needed by UCONN for generating the model-based 
organizational structure. 

• Chapter IV uses the methodology developed by Berigan to develop the 
task structure, describes the scenario and the organizational structures, 
provides details of the processes used in developing the organizations, and 
gives an overview of the conduct of experiment two. 

• Chapter V is an overview of preliminary findings from experiment two. 
The findings are beyond the designed.scope of the thesis, but are included 
for completeness and closure in order to lay a foundation for the research 
plan for NPS experiment three in November 1997. 

• Chapter VI details some modifications to the DDD simulation made for 
the second experiment, preliminary plans for additional improvements, 
and lessons learned. 

• Chapter VII is a summary of the paper and areas of future research. 

• Appendix A provides the operational orders and order modifications used 
for training and briefing the players and the quick reference sheets used 
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during the DDD-EH runs. 

Appendix B provides the data collection forms and player questionnaires. 
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II. DEFINING DIMENSIONS OF INTEREST 



A. INTRODUCTION 

To determine which types of organizations function best with different classes of 
tasks it is necessary to develop an organized and disciplined method to differentiate 
between tasks and organizations to ensure they are different. To differentiate between 
tasks, they must be characterized. This can be accomplished by decomposing each task 
into the lower levels of its various dimensions. What are the dimensions of task structure? 
Little in the literature of organizational theory and behavioral decision theory explains or 
defines dimensions of task structure. Discussions of one or several aspects of task 
structure are common (Wood, 1986, Campbell, 1988, Malone and Crowston, 1994, Ben 
Zur and Breznitz, 1981, Davis et al., 1991, Evaristo et al., 1995), but none provided a 
comprehensive exposition of these dimensions as they pertain to the A2C2 experiments 
until Michael Berigan discussed them in his thesis in 1996. Since I relied on his work in 
this particular area, I will include the applicable portions of chapter II from his thesis 
here to provide the necessary background information. 

B. LITERATURE REVIEW 

The following pages are an excerpt from Michael Berigan’s thesis. The work was 
the basis on which the tasks for the second experiment were designed. 

The literature on dimensions of task structure is mainly composed of 
articles and papers from technical journals. The works described below are the 
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most significant to date from the perspective of enumerating dimensions of task 
structure. Six articles are discussed: Wood (1986) and Campbell (1988) deal with 
complexity, Malone and Crowston (1994) consider coordination requirements, 

Ben Zur and Breznitz (1981) deal with time pressure, Evaristo et al. (1995) 
describe time pressure and uncertainty, and Davis et al. (1991) discuss task 
activities, time frame, task formalization, task ambiguity, task complexity (using 
Wood’s (1986) definition), and task significance. 

(1) Wood 

Robert E. Wood, in his article, “Task Complexity: Definition of the 
Construct” (1986), first states that tasks contain three components: (1) the 
product, or what is produced by completing the task; (2) acts, or things that must 
be done in order to complete the task; and (3) information cues, or information 
that provides the stimulus for performance of a task, or is required for the task to 
be completed. He then defines task complexity in terms of these three task 
components, and decomposes task complexity into three different components: 
component complexity, coordinative complexity, and dynamic complexity, and 
discusses methods for quantifying each of the components. 

(i) Component Complexity 
Component complexity is a direct function of the number of 
distinct acts that must be completed in the performance of the task and the number 
of distinct information cues that must be processed in order to perform the acts. 
Wood gives the sum TC,, the measure of component complexity, as the sum of 
information cues for all acts of all subtasks within the task. [Berigan, 1996) 

In experiment two, the level of component complexity at the micro level remained 
approximately the same as in experiment one, a detailed description of the scenario for the 
second experiment is contained in Chapter IV. At the macro level, many more task items 
were inserted into the scenario to increase the workload of all the decision makers. The 
purpose was to place a premium on resource utilization either by reducing existing resources 
or increasing the required tasks. 



(ii) Coordinative Complexity 
Coordinative complexity, as defined by Wood, refers to the 
relationships between task inputs and task products. It describes the form and 
strength of the relationships between information cues, acts, and products, as well 
as the sequencing of inputs. Wood gives a number of different indices with which 
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to attempt to measure coordinative complexity, most of which are a bit obscure 
and difficult to obtain, and I will not elaborate on them because of the space that 
would require. The most straightforward is the sum of all precedence relations 
between each act and all other acts in the task, which he denotes TC 2 . [Berigan, 

. 1996) 

We significantly increased the level of coordinative complexity in experiment two; 
the capabilities of the various platforms were modified such that many different possible 
combinations could be used to accomplish a given task or operation, but in many instances 
more than one platform and/or decision maker would need to coordinate efforts to bring 
sufficient assets to bear. 



(1) Dynamic Complexity 

Wood defines dynamic complexity as changes in the task 
environment which affect the relationships between task inputs and products. He 
measures this by summing the changes in TC, and TC 2 over discrete time periods, 
reduced by the change multiplied by a predictability coefficient for each time 
period, to arrive at a dynamic complexity figure denoted TC 3 . 

(2) Total Complexity 

To arrive at a figure for total complexity. Wood obtains a weighted 
sum of the TC,, TC 2 , and TC 3 totals. The specific weights, represented by 
coefficients, assigned to each sum would be situationally dependent, constrained 
by the requirement that TC, be more heavily weighted than TC 2 , and TC 2 more 
heavily weighted than TC 3 . 

i. Campbell 

Donald J. Campbell, in his article “Task Complexity: A Review and 
Analysis” (1988), took a different approach to defining complexity. He posited 
that task complexity is closely related to information, and that any task attributes 
that increase the load, diversity, or rate of change of information should be 
considered contributors to task complexity. He found four task characteristics that 
meet that criterion: the degree to which a task contains multiple paths, multiple 
outcomes, conflicting interdependence among paths, and uncertain or 
probabilistic linkages. 



(a) Multiple Paths 

Increasing the number of possible ways to complete a given task 
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increases the complexity of the task. This is particularly true if the paths vary in 
their “goodness,” that is, some paths more efficiently or effectively complete the 
task than others. Complexity is reduced if all paths presented are of equal 
goodness. 

(b) Multiple Outcomes 

Outcomes are the different results the performer of the task wants 
to achieve when the task is completed. The greater the number of different 
outcomes, the more complex the task. 

(c) Conflicting Interdependence Among Paths 
Campbell defines this as negative relationships among desired 

outcomes. If achieving one outcome conflicts with achieving another outcome, 
task complexity increases. 

(d) Uncertain or Probabilistic Linkages 
Campbell defines linkages as the connection between potential 

path activities and desired task outcomes. If there is difficulty determining these 
linkages, or the linkages have a probability of less than one, information 
processing requirements are increased significantly, and task complexity 
increases. 

ii. Malone and Crowston 

Thomas W. Malone and Kevin Crowston, in their paper “The 
Interdisciplinary Study of Coordination” (1994) define coordination as managing 
dependencies between activities. They defined four different types of 
dependencies that could need to be managed: shared resources, 
producer/consumer relationships, simultaneity constraints, and task/subtask 
relationships. 



(1) Managing Shared Resources 

Whenever more than one actor or activity requires a limited 
resource, coordination is required to ensure that the resource is properly allocated 
among the actors or activities. 

(2) Managing Producer/Consumer Relationships 

A producer/consumer relationship is one in which one actor or 
activity produces something that is used by another actor or activity. 



(3) Managing Simultaneity Constraints 
Simultaneity constraints occur where more than one activity must 
be performed at the same time as another, or when one activity must be performed 
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at a specific time in relation to the performance of another activity. 

(4) Managing Task/Subtask Relationships 

Task/subtask relationships occur when a task must be broken up 
into multiple subtasks, and the subtasks divided up among multiple actors or 
different time periods for completion. 

iii. Davis, Collins, Eierman, and Nance 
Gordon Davis, Rosann Webb Collins, Michael Eierman, and William 
Nance, in their working paper “Conceptual Model for Research on Knowledge 
Work” (1991) discuss characteristics of task environment that apply to knowledge 
tasks rather than manual tasks. They came the closest, of any work with which I 
am familiar, of attempting to somewhat comprehensively enumerate dimensions 
of task structure, although I do not believe that their enumeration is complete, or 
that they even, in some cases, considered the right dimensions. However, some of 
the characteristics they describe are quite useful. They discuss six characteristics: 
task activities, time frame, task formalization, task ambiguity, task complexity, 
and task significance, of which formalization, ambiguity, and complexity are the 
most suitable for the purposes of this thesis. 

(1) Task Activities 

Davis et al. define task activities as the operations that must be 
implemented to complete a task, with each activity being associated with one or 
more problem spaces. 

(2) Time Frame 

The amount of time it will take to complete a task. 

(3) Task Formalization 

The authors consider task formalization to be the level of 
specification and structure that is imposed on the performance of the task, or task 
inputs or outputs. A task with high formalization would be described in a very 
structured way; there are certain well-defined activities that must be performed in 
a explicit order to complete the task. In a task with low formalization, though, the 
activities required to complete the task, and even the goals of the task, would be 
poorly defined and open to interpretation. 



(4) Task Ambiguity 

Task ambiguity is defined as the clarity of understanding of the 
activities that are required to complete a task, or of the inputs or outputs of a task. 

(5) Task Complexity 



11 



The authors use Wood’s (1986) definition of complexity. 

(6) Task Significance 

Task significance is defined as the value of the task output to the 
organization performing the task, and the interdependency between task outputs 
and other operations of the organization. 

iv. Evaristo, Adams, and Curley 

Roberto Evaristo, Carl Adams, and Shawn Curley, in their article 
“Information Load Revisited: A Theoretical Model” (1995) describe three task 
characteristics: time pressure, task formalization, and task complexity. The 
authors define time pressure as the time available to perform the task, and reiterate 
Davis et al.’s (1991) definition of task formalization and Wood’s (1986) 
definition of task complexity. Their most interesting contribution is their 
description of uncertainty, although they do not consider it a task characteristic, 
but an information characteristic. They define uncertainty as knowledge 
inadequacy, resulting in an actor’s inability to predict something accurately. They 
further cite the sources of uncertainty as unavailability or incompleteness of 
information, low information reliability, and information novelty. 

v. Ben Zur and Breznitz 

Hasida Ben Zur and Shlomo J. Breznitz, in their article “The Effect of 
Time Pressure on Risky Choice Behavior” (1981) define time pressure as the 
amount of information that must be considered and processed during one time 
unit, or as the time allotted for processing a fixed amount of information. Their 
definition refers to time pressure in the information domain, but it could be 
generalized to include the task domain as well. [Berigan, 1996) 



C. DIMENSIONS OF TASK STRUCTURE 

Dimensions of task structure are the characteristics which describe and identify a task. 
To define the dimensions of task structure that are of interest in the A2C2 experiment, nine 
dimensions are detailed: uncertainty, time pressure, complexity, coordination requirements, 
magnitude, resources required, information required, task formalization, and dynamicity. 
Ideally, these dimensions should be orthogonal, but complete orthogonality would require a 
comprehensiveness that is beyond the scope of the experiment at this phase in the A2C2 
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project. As a result, there are some interactions between dimensions. For each dimension of 
task structure, a definition and an example in an operational military context are given, 
followed by a description of how any given task could be graded in that dimension. 



vi. Uncertainty 

(1) Definition 

Uncertainty is defined as the degree to which information about 
states, inputs, outcomes, or environments of tasks is unknown (Evaristo, et al., p. 
200 ). 

(2) Levels 

This dimension is difficult to quantify, and grading must be done 
on a subjective basis. There are a number of ways to subjectively grade 
dimensions, which will be used throughout this chapter. First, anchored scales can 
be used. Anchored scales are scales of measurement (from 0 to 100, for example) 
in which illustrations are given of a task that would be graded (“anchored”) at 
various points on the scale, typically the high and the low ends. For example, if 
“uncertainty” was graded using an anchored scale, an event of which absolutely 
no information about states, inputs, outcomes, or environments was known would 
be considered a “0,” and an event about which all information about states, inputs, 
outcomes, or environments was known would be considered a “100.” The benefit 
of an anchored scale is that it allows for a moderate amount of transportability, 
that is, tasks that are not necessarily being evaluated in terms of one another and 
are otherwise dissimilar can be compared using a well-anchored scale. Another 
option for subjectively grading dimensions is to use a scale such as High, 

Medium, Low, and None. This scale would be adequate in circumstances where 
the only comparison of tasks that is of interest is between two or more tasks that 
are generally being evaluated in terms of one another, and are otherwise similar. 
Grading using this scale is rather arbitrary, depending on the grader’s definition of 
the level, so its transportability is low. 



(3) Example 

A simple example of uncertainty would involve an AW ACS 
operator dealing with unknown air tracks. Since the identification and intentions 
of the aircraft are not known (incomplete information on states, inputs, and 
environments), the AW ACS operator is unsure whether to direct that the aircraft 
be shot down, warn it away, or let it continue what it is doing (incomplete 
information on outcomes). This task would be graded as Medium or High 
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uncertainty. 



vii. Time Pressure 

(1) Definition 

Time pressure is the amount of activity that must be completed 
within a given amount of time (Ben Zur and Breznitz, 1981, p. 89). Alternately, it 
could be defined as the degree to which an individual or group performing a task 
are stressed by the requirement to complete the task within a given amount of 
time. I chose time pressure as a dimension rather than Davis et al.’s (1991) task 
characteristic “time frame,” because time frame does not take into account the 
magnitude of the task at hand, while time pressure, being measured as a rate, does. 

(2) Levels 

Time pressure could be either represented using a subjective scale, 
such as High, Medium, Low, or None, or an anchored scale, or a more objective, 
quantitative scale, depending on the variation of the above definition that is being 
used. A subjective scale would suggest itself if comparing two or more dissimilar 
tasks, and the only information the researcher is interested in is whether there is 
time pressure on the task performer to complete the task within a certain period of 
time, and what the relative levels between the two or more tasks are. A 
quantitative scale would suggest itself when comparing tasks which are similar in 
most dimensions. Time pressure could then be represented as the number of 
activities or subtasks that must be completed, divided by the time available to 
complete the task. This method, unfortunately, requires a standard definition of 
activity or subtask, both in magnitude and duration. If two tasks are equal in the 
quantitative measure of time pressure described above, but one task’s subtasks or 
activities take significantly longer to perform than the other task’s, then the 
quantitative scale is inappropriate. In situations where the grader cannot with 
confidence equate the subtasks or activities of one task with those of another, time 
pressure should be graded using the subjective scale. 

(3) Example 

An example of time pressure from the Persian Gulf conflict is a 
mobile SCUD missile launcher, spotted setting up and preparing to fire. The 
identification information must be passed from the sensor to a control agency with 
the assets on hand to destroy the launcher, an asset must be assigned to destroy the 
launcher, the asset must travel to the launcher, and the asset must destroy the 
launcher, all in a matter of a few minutes 1 . This task has High time pressure, on a 
subjective scale. On an objective scale, if identifying, passing information. 



i 

This was rarely, if ever, successfully done during the Persian Gulf conflict. 
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assigning an asset, getting in position to attack, and attacking are all considered 
subtasks, and the time available is 10 minutes, then time pressure is 5/10 or 0.5 
subtasks per minute. 

viii. Complexity 

I chose a variation on Campbell’s (1988) definition of complexity over 
Wood’s (1986), for several reasons. First, Campbell’s four characteristics of 
complexity are more easily understood than Wood’s three components of 
complexity, and are more simply measurable. Second, Wood’s description of 
coordinative complexity is very close to Malone and Crowston’s (1994) definition 
of coordination, which I chose to include as a separate dimension listed in 
paragraph four below. Finally, Wood’s concept of dynamic complexity can (be) 
generalized to all dimensions of task structure, not just complexity, and it is 
included as dynamicity, in paragraph nine below. 

Complexity, then, can be defined as the degree to which a task contains 
five task characteristics: multiple attributes, multiple paths, multiple outcomes, 
conflicting interdependence among outcomes, and uncertain or probabilistic 
linkages (Campbell, 1988, p. 43). Multiple attributes has been added to 
Campbell’s original list of four characteristics on the basis of other articles. 
Specific definitions of the five task characteristics are as follows: 

(1) Multiple Attributes 

(a) Definition. The number of attributes that a task performer 
must take into account, or more than one thing that must be taken into 
consideration in order to complete the task, directly affect task complexity. The 
more attributes a task has, the more complex it is. 

(b) Levels. Multiple attributes is graded by the number of 
attributes that must be taken into consideration. 

(2) Multiple Paths 

(a) Definition. The number of paths that could be taken to 
arrive at a desired outcome (Campbell, 1988, p. 43). 

(b) Levels. This aspect of complexity is graded by the 
approximate number of paths that could be taken to arrive at the desired end state. 
In many cases, this number could be infinite, or approach infinity. When this is 
true, the evaluator should only count the major variations of paths. 

(3) Multiple Outcom es 

(a) Definition. The number of outcomes desired from a task. 
These outcomes need not be mutually exclusive (Campbell, 1988, p. 43). 
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(b) Levels. This aspect is graded by the number of different 
outcomes that the task performer needs to achieve. 

(4) Conflicting Interdependence Among Outcomes 

(a) Definition. Conflicting interdependence among 
outcomes is a negative relationship between desired outcomes. If achieving one 
desired outcome conflicts with achieving another desired outcome, complexity 
increases (Campbell, 1988, p. 44). 

(b) Levels. Conflicting interdependence among outcomes 
can be graded by counting the number of conflicts between instances of 
subparagraph (c) above. Each conflict should then be given a grade of 1 if the 
conflict is minor, 2 if it is moderate, and 3 if it is severe, or some similar scale. 
These grades should then be totaled across all conflicts so that each task has a 
single, numerical grade. 

(5) Uncertain or Probabilistic Linkages 

(a) Definition. The condition where the connection between 
the potential path activities and the desired outcomes from a task are uncertain, or 
probabilistic (Campbell, 1988, p. 45). 

(b) Levels. High, Medium, Low, or None. 

(6) Example 

A good general example of complexity is the conduct of an 
amphibious assault. The amphibious assault task contains multiple attributes 
(terrain, hydrography, enemy positions, roads, beaches, enemy reinforcement 
capability, etc.) One desired outcome of the task is to destroy or suppress enemy 
positions at or near the beachhead. There are several ways to do this ( MULTIPLE 
PATHS), such as to use close air support, naval gunfire, infiltrate SEAL or 
reconnaissance teams, or some combination. There are also many additional 
outcomes {MULTIPLE OUTCOMES) that are desired, such as to achieve surprise 
and minimize casualties. However, achieving surprise and destroying and 
suppressing enemy positions are usually mutually exclusive {CONFLICTING 
INTERDEPENDENCE AMONG PATHS) — if the commander precedes his 
amphibious assault with a heavy air and sea bombardment, he will stand a good 
chance of destroying or suppressing the enemy positions, but he will probably 
destroy the element of surprise. Finally, if the enemy’s positions at or near the 
beach are well protected and disguised, the commander is uncertain whether his 
possible actions of close air support, naval surface fire support, etc. will be able to 
successfully achieve his desired outcome of suppressing or destroying the enemy 
positions {UNCERTAIN OR PROBABILISTIC LINKAGES). 
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This example would be graded as follows: 

(a) Multiple Attributes: The task attributes that must be 
considered in an amphibious assault are objective, time available, terrain, weather, 
hydrography, friendly forces available, enemy positions, enemy reinforcements, 
enemy air threat, enemy sea threat, enemy anti-air threat, beaches, mobility on 
land, and non-combatants, for a total of 14. These are very high-level attributes, so 
it would be inappropriate to compare this task with a task in which the attributes 
were low-level. 



(b) Multiple Paths: The number of paths that could be 
taken to conduct an amphibious assault is infinite. They can be categorized into 
major variations, however. The major paths that could be taken are to conduct the 
assault (as an across-the-beach assault, vertical envelopment, or combination) 
with extensive air and naval surface fire support beach preparation, conduct the 
assault without extensive air and naval surface fire support beach preparation, 
conduct the assault while destroying/suppressing enemy positions using stealthy 
means (SEAL/Recon teams/information Warfare), or any of the three previously 
mentioned paths, plus a feint at a different location, for a total of 6 possible major 
paths. 

(c) Multiple Outcomes: High-level desired outcomes for 
the given amphibious assault task are to (a) accomplish the objective, (b) achieve 
surprise, (c) suppress enemy positions at the beach, (d) minimize casualties, (e) 
interdict enemy reserves, (f) achieve sea supremacy, (g) achieve air superiority, 
and (h) minimize collateral damage, for a total of 8 desired outcomes. 

(d) Conflicting Interdependence Among Outcomes: 
Conflicts, and the scores for each, are shown in Table 1 (correlate letters on table 
with outcomes listed in paragraph above). It should be noted that the scoring in 
Table 1 is situationally dependent; conflicts between outcomes would vary in 
different amphibious operations. 
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Table 1. Scoring of Conflicting Interdependence Among Outcomes, Where Each 
Entry On Table Represents The Conflict Between The Outcomes Represented in 
Column i and Row j 



18 



(e) Uncertain or Probabilistic Linkages: Depending on the 
situation and the accuracy and volume of intelligence available, this could vary 
from low to high. 

ix. Coordination Requirements 

(1 ) Definition 

Generally, coordination requirements is the degree to which 
dependencies between activities must be managed (Malone and Crowston, 1994, 
p. 90). This can be subdivided into external (the group with others) and internal 
(among members of the group) coordination. Four different types of dependencies 
that must be coordinated, and an example of each, are as follows: 

(a) Shared Resources. Who, among a group of actors, gets 
which available and common resources (Malone and Crowston, 1994, p. 92). 

(b) Producer/Consumer Relationships. When one member 
of a group uses the output of another, or a member of a group or the group as a 
whole uses the output of another entity, or this other entity uses the group’s or a 
member of the group’s output (Malone and Crowston, 1994, p. 93). 

(c) Simultaneity Constraints. When two or more activities 
must be scheduled or synchronized (Malone and Crowston, 1994, p. 95). 

(d) Task/Subtask. Goal selection and/or task decomposition 
within a group and/or among groups (Malone and Crowston, 1994, p. 95). 

(2) Levels 

A task would be given a grade for each of the four different types 
of dependencies listed above, and on both the internal and external level. 
Subjective grades such as High, Medium, Low, and None are probably most 
appropriate. Thus, each task would have eight coordination requirements grades 
associated with it. 

(3) Example 

(a) Shared resources: Two light infantry units each face an 
enemy armored threat, and there is only one section of antitank helicopters that 
can be used against those threats, and it is attached to one of the infantry units. 
Coordination required would be graded as High (internal) and Low (external). If 
the antitank helicopter asset is owned by an external agent, however, coordination 
required would be graded as Low (internal) and High (external). 

(b) Producer-consumer relationships: During the conduct of 
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an amphibious assault, mine clearing helicopters must be used to clear mines from 
the approach to the landing beach. The landing force, then, is the consumer of the 
mine clearing helicopters’ output. If we consider the “group” to be the amphibious 
task force, then coordination required would be High (internal) and Low 
. (external). If we consider the “group” to be the landing force, however, then 
coordination required would be Low (internal) and High (external). 

(c) Simultaneity constraints: During the latter stages of the 
same amphibious assault, an infantry unit must conduct an attack synchronized 
with close air support and naval surface fire support. If the “group” was 
considered to be the amphibious task force, the coordination required would be 
High (internal) and Low (external). If the “group” was considered to be the 
landing force, the coordination required would be Low (internal) and High 
(external). 



(d) Task/Subtask: A landing force commander is given a 
mission of taking a specific objective. He must then divide the task up into 
subtasks for his subordinate units to complete. The coordination required in this 
situation would be High (internal) and Low (external). 

x. Magnitude 

(1) Definition 

The magnitude of a task is the number of activities or subtasks that 
must be performed in order to complete the task. 

(2) Levels 

The magnitude of a task could be determined quantitatively by the 
number of activities that must be performed in order to complete the task. 
However, this requires a standardized definition of “activity,” such that one 
activity is as difficult to perform as another, and decomposition of the task to the 
point where all activities are identified. Another way to assess the magnitude of a 
task would be to use an anchored scale. For example, magnitude could be 
measured on a one to one hundred scale, with “one” representing the task of 
pressing the space bar on a typewriter, and “one hundred” representing the task of 
constructing the United States Interstate Highway System. 

(3) Example 

The task of conducting an amphibious assault has many different 
activities or subtasks that must be performed, such as clearing the beach, making a 
reconnaissance, suppressing artillery with close air support, et cetera. On the one 
to one hundred scale mentioned above, the score would be about 30 for a 
significant amphibious assault. 



20 



XI. 



Resources Required 



(1) Definition 

Resources required to complete a task is defined as the resources 
other than information that the actors must possess in order to successfully 
complete the task in question. 

(2) Levels 

Resources required could be measured quantitatively by the 
number of resources required to complete a task, or could be graded on a 
subjective “High, Medium, and Low” scale. As is the case with magnitude, one 
must take care to ensure that there is a standard definition of resource, so that five 
resources in one instance is the same as five resources in another. 

(3) Example 

A landing force is given the mission of attacking an objective, and 
that objective requires three infantry companies to effectively overwhelm it. If the 
“base unit” of resources is one infantry company equivalent, then resources 
required to complete this task is three. 

xii. Information Required 

(1) Definition 

Information required to complete a task is the information that the 
actors must possess in order to successfully complete the task in question. 

(2) Levels 

Information required is measured using the same method as 
resources required. 

(3) Example 

A Silkworm anti-ship missile site threatens an aircraft carrier battle 
group. However, it was reported in a residential area, so additional information 
(confirmation and precise location via U-2 imagery) is required before the 
commander can destroy that threat. If the base unit of information is one 
intelligence report, then information required to complete this task is two reports, 
the initial report and the confirmation report. 

xiii. Task Formalization 

(1) Definition 

Task formalization is the level of specification and structure 
exhibited by the task (Davis et al., 1991, p. 22). A task with high formalization is 
defined in a very structured way; there are certain well-defined activities that must 
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be performed in a definite sequence in order to complete the task. In a task with 
low formalization, though, the activities required to complete the task, and 
possibly even the goals of the task, are poorly defined and open to interpretation. 

(2) Levels 

This dimension is again quite subjective, and the levels should 
probably be High, Medium, Low, and None, or some other discrete scale. 

(3) Example 

The task of calling for artillery fire against a visible target is very 
well structured. There are precise procedures that the forward observer must 
follow, using specific radio nets and message formats, that are ingrained from his 
earliest training. Task formalization for an artillery call for fire is High. However, 
the task of infiltrating enemy lines and destroying a prepared defensive position is 
not well structured — there are many ways that the task could be carried out, and 
the methods used and paths taken are not well formalized, but situationally 
dependent. Task formalization for the infiltration task is Low. 

xiv. Dynamicity 

(1) Definition 

The dynamicity of a task is the degree to which one or more of the 
dimensions of the task changes over time. Dynamicity could refer to any of the 
dimensions described above, alone or in combination with others. 

(2) Levels 

This is quite subjective, and would probably best be graded as 
High, Medium, Low or None in each dimension, or possibly the number of 
changes per unit time in each dimension, if that is measurable. 

(3) Example 

Returning to our amphibious assault example, consider the task of 
conducting the assault across the beach. If the assault was conducted while the 
amphibious task force was still over the horizon, and retained the element of 
surprise, the task would be much different than if it was conducted later, when the 
amphibious task force was in view of the objective beach, and the element of 
surprise was lost. The later it was conducted, the better prepared the enemy would 
be for the assault. In each dimension, dynamicity is graded as follows: 

Uncertainty: High (The later the assault is conducted, the 
less uncertainty) 

Time Pressure: High (The later the assault is conducted, the 
more time pressure) 

Complexity: High (The later the assault is conducted, the 
more complexity) 
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Coordination Requirements: High (The later the assault is 
conducted, the more coordination required) 

Magnitude: High (The later the assault is conducted, the 
greater the magnitude) 

Resources Required: High (The later the assault is conducted, 
the more resources required) 

Information Required: High (The later the assault is 
conducted, the more information required) 

Task Formalization: Low [Berigan, 1996) 



D. EXCEPTIONS TO ORTHOGONALITY 

The dimensions discussed are distinct, but related. If we can identify the 
interrelationships between the dimensions, we can compensate for the interaction by 
preventing variations from occurring in those dimensions the experimenter desires to hold 
constant. Not all the dimensions interact with each other, Berigan listed those dimensions 
that should have little or no interaction, and then discussed how changes in one 
dimension may affect some or all of the other dimensions. 

There should be little or no interaction between uncertainty and 
dynamicity, time pressure and dynamicity, complexity and dynamicity, 
coordination requirements and task formalization, coordination requirements and 
dynamicity, magnitude and task formalization, magnitude and dynamicity, 
resources required and task formalization, resources required and dynamicity, 
information required and task formalization, information required and dynamicity, 
or task formalization and dynamicity. All other interactions are detailed below. 

xv. Uncertainty-Time Pressure 

As uncertainty increases, the number of activities that an actor would have 
to perform in order to deal with the uncertainty well enough to complete the task 
could also increase (increased magnitude). If this number of activities increases 
while the time allowed to perform the task remains constant, time pressure will 
increase. Conversely, if time pressure increases, it could force the actor to 
complete the task before he is able to obtain all the information he wants, thus 
increasing uncertainty. 

xvi. Uncertainty-Complexity 
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As uncertainty increases, complexity can also increase. The number of 
attributes that must be taken into account in order to reduce uncertainty can 
increase, thus causing greater complexity. Additionally, if the uncertainty 
decreases the probability of the linkages between path activities and desired 
outcomes, this can cause an increase in complexity. Conversely, if the complexity 
increases, it should not necessarily affect the uncertainty. 

xvii. Uncertainty-Coordination Requirements 

Changes in uncertainty can cause changes in coordination requirements. If 
uncertainty increases, whether resources must be shared, which activities must be 
simultaneous, what must be produced and consumed, or which subtasks are 
required in the performance of a task can also become more uncertain, requiring 
greater coordination for any type of dependency in which the uncertainty is 
increased. Conversely, changes in coordination requirements should not cause 
changes in uncertainty. 

xviii. Uncertainty-Magnitude 

As mentioned under “time pressure,” as uncertainty increases, the number 
of activities that an actor must perform in order to alleviate the uncertainty could 
increase, thus increasing the magnitude of the task. Conversely, an increase in 
magnitude could force the actor to complete the task before he is able to obtain all 
the information he wants, thus increasing uncertainty. 

xix. Uncertainty-Resources Required 

As uncertainty increases, resources required could increase, if those 
resources would be used to decrease the uncertainty or, in a case that involves two 
or more uses for certain resources, the uncertainty is enough so that the 
decisionmaker desires to use resources for all potential paths, in order to “cover 
all bets.” An increase in resources required would not tend to drive an increase in 
uncertainty, however. 



xx. Uncertainty-Information Required 

As uncertainty increases, information required could also increase, because 
the decisionmaker would want more information in order to reduce his 
uncertainty. Changes in information required, though, should not cause changes in 
uncertainty. 

xxi. Uncertainty-Task Formalization 

Increases in uncertainty could also elicit increases in task formalization, 
since the uncertainty can involve the structure and paths taken to complete the 
task. This is not necessarily so, however; a task can still be highly formalized and 
well structured if some or many of the states, inputs, outcomes, or environments 
are not well known. Changes in task formalization should not drive changes in 
uncertainty. 
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xxii. Time Pressure-Complexity 

Changes in time pressure can cause changes in complexity. If the time 
pressure decreases, the number of attributes or paths that can be considered can 
increase, because of the additional time the decisionmaker has to consider them. 
Also, uncertain or probabilistic linkages can decrease if time pressure decreases, 
because the decisionmaker has additional time to reduce his uncertainty. 
Conversely, changes in complexity can cause changes in time pressure. If 
complexity decreases, the amount of time that the decisionmaker must devote to 
sorting out the situation also decreases, and, if the amount of time available 
remains constant, time pressure will decrease. 

xxiii. Time Pressure-Coordination Requirements 

Changes in time pressure can affect coordination requirements. If the time 
pressure increases, coordination between two or more entities can become more 
difficult, or even impossible, because the time available to communicate and 
synthesize is lessened. Conversely, changes in coordination requirements can 
cause changes in time pressure. If coordination requirements are lessened, the 
amount of activities that must be performed is generally lessened, because some 
of those activities are coordination-related, such as the actors communicating with 
one another. Lessening the number of activities while holding the time available 
constant reduces time pressure. 

xxiv. Time Pressure-Magnitude 

Since time pressure and magnitude are directly related (time pressure is 
magnitude divided by time available), changes in one will cause changes in the 
other, unless the time available is modified accordingly. 

xxv. Time Pressure-Resources Required 

Changing time pressure would tend to have an inverse effect on resources 
required. If time pressure was increased, the resources required would tend to go 
down, because the actors would not have time to use all the resources that are 
available to them. Changes in resources required would tend to have a direct 
effect on time pressure — if resources required was increased, then time pressure 
would increase, because of the additional activities that would probably be 
required to put those resources to use, as long as time available is held constant. 

xxvi. Time Pressure-Information Required 

This interaction should be the same as the time pressure-resources required 
interaction. 

xxvii. Time Pressure-Task Formalization 

As time pressure is increased, task formalization would tend to increase, in 
those instances where there is a more structured way to perform a task that may 
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not achieve the goals of the decisionmaker as well as a less structured method 
will, but the more structured method would tend to take more time. As task 
formalization is increased, time pressure would tend to decrease, because more 
formalized tasks would tend to take less time because of the well-defined nature 
of the activities involved. 

xxviii. Complexity-Coordination Requirements 

Complexity and coordination requirements can affect each other in many 
subtle ways. For instance, if the number of possible paths is increased, 
coordination requirements could be increased, because of a possible requirement 
to coordinate with other team members in order to explore the paths. Or, 
increasing a shared resources requirement could increase the number of possible 
paths that could be taken. Changes to either of these dimensions must be 
scrutinized carefully to ensure any effect on the other has been accounted for. 

xxix. Complexity-Magnitude 

Increasing complexity can increase the magnitude of a task. If, for 
instance, additional activities must be performed in order to resolve a complex 
issue, then magnitude will increase. Additionally, if the magnitude of a task 
changes, and the added or decreased activities affect the number of attributes, 
paths, outcomes, interdependence, cues, or linkages present, then the complexity 
could increase or decrease as well. 

xxx. Complexity-Resources Required 

Increasing complexity of a task might require a different system or more 
personnel to aid in problem-solving than a more simple task would, thus 
increasing resources required. If resources required to complete a task were 
decreased, then complexity could decrease also, because the decrease in resources 
required could result in fewer attributes or paths that must be considered by the 
decisionmaker. 

xxxi. Complexity-Information Required 

Increasing the complexity of a task could increase information required, 
because the decisionmaker might want more information in order to help choose 
the right path, or decrease uncertainty of linkages between paths and outcomes. 
Increasing the information required could also increase task complexity, because 
the additional information required could be an additional attribute that the 
decisionmaker must consider. 

xxxii. Complexity-Task Formalization 

Increasing complexity can decrease task formalization. As the number of 
attributes, paths, and desired outcomes grows, the chore of formalizing a task can 
become more difficult, such that many extremely complex tasks are not 
formalized at all, because of the number of characteristics that must be 
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considered. Increasing task formalization may or may not increase complexity. 
Increasing formalization and adding a structured way of looking to the 
decisionmaking process could have the effect of decreasing complexity, or at least 
making the complexity more easily manageable. 

xxxiii. Coordination Requirements-Magnitude 

Increasing coordination requirements could increase the magnitude of a 
task, because greater coordination requirements could result in additional 
activities that must be performed in order to coordinate actions. Changes in task 
magnitude, however, should have little or no effect on coordination requirements, 
unless the activities that were added or deleted specifically involve use of shared 
resources, a producer/consumer relationship, a simultaneity constraint, or the task 
must be decomposed into subtasks by the decision makers. 

xxxiv. Coordination Requirements-Resources Required 

Changes to the coordination requirements should not affect resources 
required to perform a task. Increases in resources required, though, could cause 
coordination requirements to increase, because the additional resources required 
could cause a necessity to share available resources where one did not exist 
before, unless the resources available were also increased. 

xxxv. Coordination Requirements-Information Required 

Changes to coordination requirements should not affect information 
required. Increases in information required could lead to increases in coordination 
requirements, because the decision makers might need to coordinate actions in 
order to obtain the additional information. 

xxxvi. Magnitude-Resources Required 

Changes in the magnitude of a task should not affect resources required to 
complete a task, unless the added activities require more resources to perform 
them. Changes in resources required, however, could change the magnitude of a 
task, if the additional resources needed additional activities to be performed in 
order to put the new resources to use. 

xxxvii. Magnitude-Information Required 

Changes in the magnitude of a task should not affect information required 
to complete a task, unless the added activities require more information in order to 
perform them. Changes in the information required, however, could change the 
magnitude of a task, if the actors had to perform additional activities in order to 
obtain the added information. 



xxxviii. Resources Required-Information Required 

Changes in resources required to complete a task could cause changes in 
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information required, if the additional resources needed additional information in 
order to put the resources to use. Conversely, changes in information required to 
complete a task could result in changes in resources required, if the new 
information requirement needed additional resources in order to obtain the 
information. [Berigan, 1996) 

E. SUMMARY 

This chapter enumerated the dimensions of task structure, defined them, and 
demonstrated a method of grading the dimensions. These dimensions will be used to vary 
the overall complexity of the tasks/missions in the experiment as we develop the 
“ triggers ” or “ vignettes ” which will be used to stimulate adaption in the test 
organizations. Michael Berigan’s review of the pertinent literature surveyed the possible 
sources of information and various opinions on dimensions of task structure. A set of task 
dimensions appropriate for the purposes of the A2C2 project was developed and defined 
and a comprehensive breakdown of these dimensions was provided. Exceptions to 
orthogonality of the dimensions were identified to aid in compensating for any effect 
which changes to one dimension might have on other related dimensions. 
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III. TASK STRUCTURE DIAGRAM AND TASK DESIGN PROCESS 



‘ This chapter focuses on the development of a task structure diagram concept. 
Definitions necessary to discuss decomposition of tasks into component subtasks and 
actions are given and the task structure diagram is described. The specific features and 
capabilities of the diagram are discussed followed by a description of how the 
dimensions of task structure developed in the previous chapter relate to the diagram. 
Finally, the concepts of Chapter II and this chapter are synthesized into a task design 
process that can be used to develop military operational scenarios, or more general tasks, 
in an experimental context. 

A. INTRODUCTION 

Determining the dimensions of task structure is an important area of experimental 
design for the A2C2 project. It establishes the groundwork for designing and 
differentiating tasks based on dimensions. Once dimensions are defined, a method is 
developed to assist the experimenter in visually describing the task structure, flow, and as 
many of the dimensions defined in Chapter n as necessary for expository purposes. A 
visual method makes the task design and differentiation less complex. 

B. DEFINITIONS 

The development of a task structure diagram involves decomposing tasks to the 
lower level activities from which they are constructed. In order to discuss the subject, we 
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must have common definitions for the various activities and define what is meant by task 
structure and task structure diagram. For the purposes of continuity in the A2C2 Project, I 
will use the same definitions for these terms as Michael Berigan’s work for experiment 1. 



1. Activity 

An activity is any act that must be performed, at a high or low level of task 
decomposition. For our purposes, it is a generic term encompassing tasks, 
subtasks, and actions. 

2. Task 

A task is the macro level activity. It describes the overall activity that is 
being performed by the actors. Since it is really impossible to define beforehand 
the magnitude of the task, for our purposes, it is defined as the level that is the 
primary focus of the study. 

3. Subtask 

A subtask is a next-lower level component of a task. The nodes on a task 
structure diagram are subtasks. There can be more than one level of subtasks; if 
there are multiple layers, the highest layer of subtasks is subtask level 1 . 

4. Action 

Actions are activities that are in their most elemental state for the uses of 
the study. Actions are either not further decomposable, or further decomposition 
would be impractical or would serve no purpose. 

5. Task Structure 

Task structure is defined as the flow of subtasks within a task in the time 
domain. 



6. Task Structure Diagram 

A task structure diagram is a visual model of a task which describes the 
task structure, and as many characteristics of a task as practical. The task structure 
diagram is designed to simplify understanding of the task and manipulation of 
potential variables. (Berigan, 1996) 
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c. 



TASK STRUCTURE DIAGRAM 



Task structure diagrams based on Hatley and Pirbhai’s data flow diagram (DFD) 
concept (Hatley and Pirbhai, 1988) will be used to provide a visual representation to 
experiment designers of the flow of subtasks and actions within a task. Dimensions of 
task structure are represented directly or inferred from this task structure diagram. By 
visualizing the structure of a task, experimenters are able to determine if a task 
accomplishes the objectives that have been set. Task structure diagrams provide a 
straightforward, pictorial method for comparing tasks and for describing a task outside 
the scenario design process. Experiment designers can also delineate task structures they 
are interested in testing, and the scenario developed to fit that structure. This “object 
oriented” view of task structure design allows designers to treat activities and nodes as 
modules, rearranging as necessary to achieve experiment scenario goals and objectives. 

Highly structured or formalized tasks are easily described using this method, but 
some tasks are composed of numerous alternative subtasks. The alternative path options 
grow exponentially, until the labor involved in developing the diagram outweighs the 
benefits gained from its use. Figure 1 is an example of a task structure diagram. A 
description of the diagram and its building blocks is provided. 2. 

1. Flow Description 

Each diagram represents one task or subtask. The individual subtasks and 
actions within each task or subtask are the nodes, represented by the circles or 
rectangles. The task flows in time from the “start” box to the completion of the 
final subtask. Thus there may be many “levels” of diagrams for each task. 



31 



Task 1 



Subtask 1 



Subtask 6 




I Subtask 5 



Subtask 7 




Code for diagram 
DM I task Bold print 

DM2 task Italic print 

Common task Regular Print 

Competitive task Underlined print 
Static task Rectangle 

Dynamic task Oval 

Decomposable task Dotted boundary 
Parallel or Bold connection 

Simultaneous Tasks 

OR operator 

AND operator 

Hard Prereq. 



Soft Prereq. 



^ubtaslH^ 



Figure 1: Task/Subtask Level Task Structure Diagram (from Berigan, 1996) 
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2. Actors 

Actor refers to the Decision Maker who performs each subtask in Figure 1 
and is represented by the style of type used for the name of the subtask. For 
example, if the subtask is given in bold type, then DM 1 is the task performer, if 
the subtask is given in italic type, then DM 2 is the task performer. If the subtask 
is in normal type, then both Decision Makers are involved in the subtask. If there 
are more than two actors are involved in a task, then a identification schema 
would have to be used. In Figure 1 , decisions for subtasks 2 and 5 are made by 
DM 2, decisions for subtasks 3,4,7, and 9 are made by DM 1. All the other 
subtasks are common tasks and may be performed by several DM’s. ( This section 
of text from Berigan 1996 was modified to correct for figure number and changes 
to the figure.) 



3. Decomposability 

Decomposability implies that a task or subtask can be divided further into 
lower level subtasks or actions (Simon, 1981, pp. 196-210). Decomposability will 
be represented by the border of the figure representing each activity. A solid 
border represents an item that is not decomposable — the task, subtask, or action 
represented is at its most basic level. A dotted border represents an activity that 
can be broken down into lower level activities. 

4. Simultaneity (same as Parallel) 

Simultaneity is the requirement that two or more activities are to be 
performed concurrently or must be synchronized. Simultaneity is a dependency 
between actions that is included in the coordination requirements. Simultaneity is 
represented by a bold line joining the activities which have this dependency 
relationship. 

5. AND Operator 

The AND operator implies that all the activities feeding into it must be 
completed before the activities following it can be performed. The AND operator 
is represented in the diagram by a half-moon shape. 

6. OR Operator 

The OR operator indicates the requirement that one of the activities 
feeding into it must be completed before the activities following it can be 
performed. The OR operator is represented in the diagram by a crescent shape. 



7. Competition 



Activities are competitive if two or more actors require the same resource 
simultaneously to accomplish them. Competition is represented by underlining the 
title of the Competition is another of the coordination requirements dependencies, 
shared resources. 

8. Dynamicity 

Dynamicity is a measure of the change to one or more of the dimensions of 
a task over time. The shape of the figure representing the activity indicates 
Dynamicity; rectangles are non-dynamic, or static subtasks, and ovals are dynamic 
subtasks. 

9. Prerequisites — Hard and Soft 

Prerequisites are the activities that are performed prior to another activity. 
A prerequisite is considered a hard prerequisite if it must be performed prior to 
performing a given activity. A hard prerequisite is represented in the diagram by a 
solid arrow (line) connecting activities. A soft prerequisite is an activity which 
should be performed prior to a given activity for optimal results, but the following 
activity can be accomplished without the prerequisite being performed first. A soft 
prerequisite is denoted by a dashed arrow (line) connecting activities. 

10. Decomposing Tasks into Subtasks and Actions 

Figure 1 represents a task broken into subtasks. Some of the subtasks are 
in their elemental state — they are at the lowest activity or action level. Others can 
be decomposed at least one more level, some can be decomposed several more 
levels. Figure 2 represents a subtask decomposed into its elemental component 
actions. 



11. Elemental State Task Structure Diagrams 

The elemental state task structure diagram follows the same format as 
previously discussed for the task structure diagram. The elemental state task 
structure diagram contains a breakdown of the dimensions (see Chapter II) of task 
structure that apply to each action not previously shown in the task structure 
diagram (only those that are graded as other than “Low” or “None”), and the 
resources and information required to complete the action. (Berigan, 1996) 
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Subtask 3 




Action 2 




Uncertainty 


Med 


Time Press 


High 


coordination req. 


High, Int. 


Resources req. 


R 1 ,2 


Info Req. 


Item 3,4 



Action 3 




Uncertainty 


High 


Time Press 


High 


coordination req. 


High, Ext. 


Resources req. 


R4,6 


Info Req. 


Item 1,3 




Figure 2: Subtask Decomposed To Its Most Basic Components 
(Berigan 1996, p 41) 
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D. OPERATIONALIZING DIMENSIONS OF TASK STRUCTURE IN A 
TASK STRUCTURE DIAGRAM 

For the task structure diagram and the dimensions of task structure to be of any 
use to us, we must be able to link the two issues. Each dimension of task structure must 
be delineated in the task structure diagram. Delineation of some of the dimensions in a 
task or subtask is straightforward, while others are more subtle. The manifestation of 
each of the nine dimensions of task structure in the task structure diagram is detailed in 
this section. 



1. Uncertainty, Time Pressure, Complexity 

Uncertainty, time pressure, and complexity are shown in the task structure 
diagram by assigning them a value in the diagram that shows a task in its most 
elemental state, (See Figure 2). The score for a subtask in each of these 
dimensions is the mean of the grades (scores) of all the actions that comprise the 
subtask; the score for a task in each dimension is the mean of the grades (scores) 
of all the subtasks that comprise the task. (Figure number modified to correspond 
to proper figure) 

2. Coordination Requirements 

Coordination requirements are shown several ways in the task structure 
diagram. If the grade for each dependency is High or Medium, it will be listed 
with the action in which it is associated on the elemental state task structure 
diagram. The different types of dependencies are represented in the diagram in the 
following ways: 



a. Shared Resources 

Competitive subtasks that are underlined implies competition over 
shared resources at a scoring level of Medium or High. 

b. Producer/Consumer Relationships 

Hard prerequisite indicators (a solid arrow connecting activities) in 
a task structure diagram imply that a producer/consumer dependency exists, the 
follow-on activity cannot be performed until the first is complete. 
Producer/consumer dependency is graded as Medium or High. A high score 
indicates a task or subtask that cannot be accomplished out of sequence, a medium 
score indicates the task or subtask can be completed out of sequence but 
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performance score will be significantly degraded. 

c. Simultaneity Constraints 

Simultaneity indicators (a solid bar connecting the activities) in the 
task structure diagram imply that simultaneity constraints are Medium or High. 
High indicates tasks or subtasks that must occur at the same time, medium 
indicates tasks that should be performed at the same time for maximum 
performance score. 

d. Task/Subtask 

The task structure diagram shows the breakdown of a task into its 
component subtasks and actions, and also depicts which actor or DM is assigned 
to complete each task or subtask. This is not the same as the allocation of tasks or 
subtasks by the DM’s in the actual runs. This is the task/subtask dependency 
which not manifested in the diagram itself, except as the grade given in the 
elemental state task structure diagram .(Inserted for clarification of Berigan’s 
work. In order for UCONN modelers to input the data into the model, they needed 
to have tasks and subtasks assigned to DMs or nodes, this was provided by the 
task structure diagram. This was not necessarily the actual division of labor that 
resulted in the experimental runs.) 

3. Magnitude 

The magnitude of a task is determined by counting the total number of 
actions in the task structure diagrams, starting at the highest level and breaking the 
task down to its elemental states. 

4. Resources and Information Required 

Resources and required information are listed in the elemental state task 
structure diagram. Counting the total resources and pieces of information required 
for each action within a task gives the total resources and information required for 
the task. 

5. Task Formalization 

Indicators of task formalization in the diagram are the ratio of soft to hard 
prerequisites (more soft prerequisites would imply less formalization), and the 
number of “or” operators (fewer “OR” operators implies more formalization). A 
task that can be readily displayed using the task decomposition method would 
have at least a medium level of formalization. Attempts to decompose tasks with 
low formalization would numerous alternative paths that decisions makers could 
take with no degradation in performance scores. (Berigan, 1996) 
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E. DESIGNING THE TASK 



The scenario development and task design problem identified in Chapter I can 
now be approached in a straightforward manner. The process consists of four steps: 

1 . Determining the dimension of task structure of interest. 

2. Determining the desired task structure. 

3. Developing the scenario. 

4. Grading scenarios by dimensions. 

The second and third steps are interchangeable. This process will often be 
iterative, with at least the second, third, and fourth steps repeated more than one time. 

1. Dimension of Interest 

The goals of the experiment determine the dimension(s) of task structure (if any) 
that are of interest. If a task structure dimension is of interest, then task structure will 
usually be an independent variable. A researcher must determine what his dimension(s) of 
interest will be. He should then determine the number of levels needed based on the 
constraints of his experiment, and at least an approximation of the values the levels will 
take on. The researcher should also determine any of the other task structure dimensions 
he desires to hold constant, if important to his investigation. 

2. Desired Task Structure 

Several options are available for sequencing the development of the task structure 
diagram. If a specific structure or characteristic (such as simultaneity) is desired then a 
preliminary task structure diagram should be developed after the dimension of interest 
has been determined, filling in detail as the scenario is written. If no specific task 
structure requirement for the experiment exists, then the task structure diagram should be 
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developed concurrently with the scenario, using it as a briefing, explanation, editing, and 
grading tool. 

3. Scenario Development 

The scenario development should take dimension(s) of interest and desired task 
structure into consideration as well as ensuring the experiment fits within the other 
constraints and limitations, such as project context, other independent variables, subject 
pool, time and resources available, et cetera. 

4. Grading Dimensions of Task Structure in Scenarios 

In order to determine whether dimensions differ or are held constant, the 

scenario(s) should be graded based on the levels of dimensions of task structure as 
described in Chapter EL 

F. SUMMARY 

In this chapter a visual representation of a task’s structure was developed using 
the data flow diagram (DFD) concept of Hatley and Pirbhai. Definitions necessary to 
discuss task decomposition were provided and the task structure diagram and its features 
described. The task structure diagram provides the dimensions of task structure, shows 
the flow of subtasks and actions in the time domain, and depicts optional paths, hard and 
soft prerequisites, and decomposability. A methodology was developed for designing a 
military operation scenario based on task structure. 
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IV. SCENARIO AND ORGANIZATION ARCHITECTURE FOR 
THE SECOND A2C2 EXPERIMENT 



This chapter focuses on the development and modification of the scenario and 
organizational structures from the first NPS experiment for use in the second A2C2 NPS 
experiment. The second experiment evaluates two different organizational structures, one 
model-based, developed at UCONN, and the other developed at NPS using current 
military doctrine as the basis for its design. The tools developed in the preceding chapters 
are used to design the scenario tasks, develop an organizational structure, and provide 
inputs to UCONN modelers for generating their model-based, optimized organizational 
structure. A description of the resulting NPS and model-based organizational structures 
and an overview of the conduct of the experiment are also presented. 

A. INTRODUCTION 

The background information provided in Chapters II and in showed how a 
paradigm was developed for visually representing task structure, determining levels of 
dimensions of task structure, and stipulating a process for designing a task based on the 
task structure dimension of interest and desired task structure. The main focus of this 
thesis, the second NPS experiment of the A2C2 program, used this paradigm to design 
the experimental tasks and supporting scenario. An organization plans and prepares to 
accomplish a mission or task by the assigning its resources to appropriate DMs 
(commanders) in an organizational structure designed to accomplish that mission. 
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Investigating organization adaption is the primary goal of the A2C2 project. A 
basic premise of the A2C2 program is that an organization’s structure should be 
"designed" based on resources available and tasks required to complete the assigned 
mission and that “significant” changes to the mission/task structure or a change in the 
organization’s assets should induce changes in the organization’s structure. The A2C2 
research team elected to use an analytic-empirical approach to conduct model-driven 
experiments with human organizations in the context of a joint military scenario to 
examine these and other hypotheses in a controlled laboratory environment. 

The NPS experiments thus far have utilized the Distributed Dynamic 
Decisionmaking (DDD-EH) software (Kleinman, Young and Higgins, 1996), which was 
developed at UCONN and installed at NPS and other sites to support studies in 
organizational theory. The design of the second experiment is an extension of experiment 
one conducted at NPS in early 1996 (Kemple, Kleinman and Berigan, 1996). 

The context for experiment two involved a Joint Task Force (JTF) in a six-node 
organizational hierarchy conducting a multi-faceted amphibious scenario that included 
maritime, ground, and air activities. The challenges of determining the dimensions of 
task structure to be varied, the task and organizational structures, and the development of 
a scenario for the second experiment will be discussed in this chapter. 

Several issues needed to be resolved while designing the experiment: 

• How to measure an organization’s performance as they perform the same 
tasks, but with resources assigned to different organizational nodes that are 
also structurally different. A variety of task structures were required to see 
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if interactions between task and organizational structures exists. 

• How can internal and external stimuli (called triggers) that are essentially 
equivalent in terms of the task load to resource ratio, be injected into the 
scenario to induce adaptation in the organizations. An internal stimulus is 
a change to resources or capabilities of the organization. An external 
stimulus is a change in the environment or mission. 

Following is a description of the development of the scenario, organization 
structures, and the design and conduct of the second experiment. 

B. DETERMINATION OF THE DIMENSIONS OF INTEREST 

Coordination requirements between DMs to share limited resources to complete 
complex tasks is the task structure dimension of interest for the second experiment. A 
complex task is one that requires more than one resource type to be successfully 
completed. 

The coordinated resources dependency varied over level one, internal coordination 
of resources -- the DM responsible for completing a task owns all the assets necessary to 
accomplish it; and level two, external coordination of resources -- the DM responsible for 
completing a task must work with one or more DMs to obtain the assets necessary to 
accomplish the task. Although it was desired to define dimensions of task structure that 
were independent from the organizational structures, whether the coordination for a 
particular task is internal or external is a function of the design of the organizational 
structure. (See Chapter II) The coordinated resources dependency level was a between 
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teams factor, with the TA teams experiencing a higher level than the NTA teams. This is 
because the NTA structure was specifically designed to minimize this dimension among 
other things. It was desired that all other dimensions of task structure be the same for both 
architectures until the triggers were introduced (discussed below). 

The efficiency and performance of the organizational stmctures was of interest in 
the second NPS experiment. The organizational structures were: model-based, 
operationally-based, and dynamically selected by the subjects during the planning 
sessions. (The dynamically selected architectures will be discussed in Chapter V. The 
players did not function in the dynamically selected architectures as part of the second 
NPS experiment, but they are being evaluated with simulations by other research teams.) 
This interest results in the following research questions: 

1. Does the performance of the model-based organization match the model’s 
predictions of performance? 

2. In the face of an internal “trigger”, do teams adapt by changing organizational 
architectures? 

3. In the face of an external “trigger”, do teams adapt by changing organizational 
architectures? 

4. Do organizations adapt their organizational structures based on changes in 
mission task and resources available? 

5. Why and how do organizations adapt? 

6. Are some organizational structures able to accommodate changes to mission or 
resources better than others (without a drop in performance)? Are some organizations 
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more robust than others? If so, why? 

7. Can the model-based organizational structures developed by the modelers at 
UCONN, based on task structure and available resources, perform as well or better than 
organizational structures developed by the traditional method used by operational 
commanders as measured by performance, resources utilization, mission accomplishment, 
and losses? 

These questions were the foundation for developing the hypotheses that were 
proposed for testing in the second NPS experiment. 

C. RESEARCH ISSUES AND HYPOTHESES 

From the goals and objectives of the A2C2 project and the general research 
questions described above, the A2C2 team formulated several general research issues 
which are the basis for the hypotheses of all the A2C2 experiments. These are: 

1 . Can model-based tools predict the optimum organizational structure to 
complete a mission given the task structure, available resources, and constraints? 

2. Can the drivers for organizational adaptation be identified? 

3. Can an adaptation to other organizational structures that perform better be 
predicted by model-based tools after task structure or resource changes ? 

From these research issues, the major null and alternative hypotheses for the 
second NPS experiment were developed: 

H 0l : There is no interaction between task structure and organization structure, 
when coordination requirement is the dimension of interest. 
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H al : There is interaction between task structure and organization structure, when 
coordination requirement is the dimension of interest. 

H o2 : Changes in levels of tasking will not cause organizations to adapt. 

H a2 : Changes in levels of tasking will cause organizations to adapt. 

H o3 : Changes in levels of resources will not cause organizations to adapt. 

H a3 : Changes in levels of resources will cause organizations to adapt. 

These hypotheses are based on the assertion that an organization will design its 
resources and organizational structure to accomplish its mission within acceptable limits 
of applicable constraints such as expected mission duration, total losses, casualties, and 
damage (own, enemy, and collateral), and other costs. The resources and tasks required to 
achieve a mission will influence the structure of the organization. Based on 
organizational theory (class notes from MN 3105, Organizational Structures, Fall Quarter 
1996) the organization should adapt its structure when mission changes affect the task 
structure or there is a change in the availability of resources. This is most likely 
dependent on the degree of change in the mission, task structure, or resources. If the 
mission may be successfully completed by the existing organizational structure, there may 
be no adaptation. The motivation to change is based on the tradeoff between improved 
performance gained and the costs to reorganize. When the task or resource changes 
become large enough to affect the probability of successfully completing the mission, in 
the opinion of the commander, I believe this will induce change in the organizational 
structure. This will be investigated in experiment three at NPS in November 1997. 
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D. DESIRED TASK STRUCTURE 



The mission, characteristics, task structure, and types of resources used in the 
first NPS experiment that were compatible with the goals of the second NPS experiment 
were reused where possible. This allowed more effort to be devoted to the organizational 
structure issues. Many of the same parameters and dimensions designed into the first 
experimental scenario were of interest in the second experiment. A higher level of 
workload on the DMs was desired as was a more balanced workload among DMs, so 
additional background tasks were added to the scenario. A background task is a minor 
task that can be handled by one asset or platform without assistance from, or coordination 
with, other DMs. The purpose behind a background task is to increase the workload on 
DMs and cause distractions, resulting in increased stress, time pressure, and ambiguity on 
the DMs. 

1. Formalization of Scenario Task Structure 

To test our hypotheses, the experiment was designed to measure the performance 
of teams attempting to perform the same mission, given the same resources and task 
structure, but using different organizational structures. Therefore a high degree of 
formalization in the design of the experiment was used, resulting in a consistent overall 
task structure form and replicable events that occur during each trial. The two initial 
organizational structures, traditional, and nontraditional, were perturbed by the systematic 
introduction of two levels of two factors, resource inventory at normal and reduced levels 
and task load at normal and increased levels. Traditional (TA) is the name given to the 



47 



organizational structure developed by the NPS researchers, nontraditional (NTA) is the 
name given to the model-based organizational structure developed by the modelers at 
UCONN. Replication and counterbalancing were used to control for other factors that 
might confound the results. 

Based on the hypotheses for this experiment and the selection of the coordination 
requirement dimension of task structures, “limited capability” resources were used in 
order to require coordination between platforms and possibly DMs to successfully 
complete the assigned mission. A military force/platform may have the capability to 
complete more than one task or perform the same task in more than one way. For 
example, a DDG, in a real engagement, might fire enough rounds from a 5" gun to ensure 
destruction of a target without using ground troops or air support. In the experiment, if an 
asset could launch/conduct more than one attack at a time to perform a given task, DMs 
would be able to avoid the coordination requirements by assigning multiple attacks on a 
target by a single platform. Since the coordination events were the focus of the 
experiment, platforms were only allowed to conduct one attack on a single target at a 
time. An additional constraint placed on the attacks requiring coordination was that 
cooperating DMs only had a ten second window within which to commit their assets to 
the simulated attack, otherwise DDD considered them as separate attacks. 

DDD requires certain amounts and types of resource mixes to successfully engage 
a target. If inappropriate assets are used, enemy targets escape unscathed and DDD 
subtracts team performance points. If inadequate resources are used, enemy targets are 
destroyed but the team loses performance points. An inappropriate attack is one that has a 
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zero capability value summed across participating resources (platforms) in one or more of 
the vector attributes required by the task. An inadequate attack was one that had a 
capability value summed across participating resources greater than zero but less than the 
task attribute vector value. See Tables 2 and 3 for examples of resource and task attribute 
vectors, they are discussed in detail later in this chapter. As an example, the amphibious 
landing on blue beach, listed as B. Beach row in Table 3, requires ten units of ground 
assault, twelve units of fire support, and eight units of armor. An appropriate attack (from 
Table 2) could consist of one rifle company and one section of CAS, the totals for this 
combination of assets would be two units of air, three units of ASUW, ten units of ground 
assault, twelve units of fire support, ten units of armor, ten units of hold, and two units of 
mine land; this meets or exceeds the required values for the task, other combinations of 
resources to successfully complete the task are also possible. An inappropriate attack 
could be two DDGs and a Cobra section. The totals for this attack would be 23 units of 
air, 24 units of ASUW, two units of ASW, 24 units of fire support, 13 units of armor, and 

I unit of mine land. Since the task requires ten units of ground assault and the assets 
attacking have zero ground assault capability, the attack is inappropriate. An inadequate 
attack could consists of one rifle company and a DDG. The totals for this attack would be 

I I units of air, ten units of ASUW, one unit of ASW, ten units of ground assault, 1 1 units 
of fire support, eight units of armor, and ten units of hold. Since the task requires twelve 
units of fire support, the attack lacks sufficient combat potential in that one category, 
even though there is adequate combat potential in all other categories. 
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Asset 


AIR 


ASUW 


ASW 


GND 

ASLT 


FIRE 

SUPP 


ARMOR 


HOLD 


MINE 

SEA 


MINE 

LAND 


MED 


DDG 


10 


10 


1 


0 


9 


6 


0 


0 


0 


0 


FFG 


1 


4 


10 


0 


4 


3 


0 


0 


0 


0 


CG 


10 


10 


1 


0 


9 


2 


0 


0 


0 


0 


CV 


0 


0 


0 


0 


0 


0 


0 


0 


0 


0 


LSD 


0 


0 


0 


0 


0 


0 


0 


0 


0 


0 


LHA 


0 


0 


0 


0 


0 


0 


0 


0 


0 


0 


LPD 


0 


0 


0 


0 


0 


0 


0 


0 


0 


0 


Eng Pit 


0 


0 


0 


2 


0 


0 


2 


0 


10 


0 


RFLECO 


1 


0 


0 


10 


2 


2 


10 


0 


1 


0 


Str Det 


5 


0 


0 


0 


0 


0 


0 


0 


0 


0 


COBRA 

SEC 


3 


4 


0 


0 


6 


10 


0 


0 


1 


0 


Cas Sec 


1 


3 


0 


0 


10 


8 


0 


0 


1 


0 


Ftr Sec 


6 


1 


0 


0 


1 


1 


0 


0 


0 


0 


Huey 

Med 


0 


0 


0 


0 


0 


0 


0 


0 


0 


10 


MCM 

HUEY 


0 


0 


0 


0 


0 


0 


0 


10 


0 


0 


RECON 

AIRCFT 


0 


0 


0 


0 


0 


0 


0 


0 


0 


0 


AAAV 


0 


0 


0 


0 


0 


0 


0 


0 


0 


0 


MV-22 


0 


0 


0 


0 


0 


0 


0 


0 


0 


0 



Table 2: Platform Attribute Vector values 



Task 


AIR 


ASUW 


ASW 


GND 


FIRE 


ARMOR 


HOLD 


MINE 


MINE 


Name 








ASLT 


SUPP 






SEA 


LAND 


Hill 


0 


0 


0 


10 


12 


8 


0 


0 


0 


R. Beach 


0 


0 


0 


0 


12 


8 


0 


0 


0 


B. Beach 


0 


0 


0 


10 


12 


8 


0 


0 


0 


Seaport 


0 


0 


0 


20 


10 


4 


0 


0 


0 


Airport 


0 


0 


0 


20 


10 


4 


0 


0 


0 


Artillery 


0 


0 


0 


0 


0 


6 


0 


0 


0 


FrgLanhr 


0 


0 


0 


0 


0 


6 


0 


0 


0 


Silkwm 


0 


0 


0 


0 


0 


6 


0 


0 


0 


L. Mine 


0 


0 


0 


0 


0 


0 


0 


0 


3 


S. Mine 


0 


0 


0 


0 


0 


0 


0 


10 


0 


StrikeAir 


5 


0 


0 


0 


0 


0 


0 


0 


0 


Tac Air 


10 


0 


0 


0 


0 


0 


0 


0 


0 


Helo 


5 


0 


0 


0 


0 


0 


0 


0 


0 


Neu. Air 


1 


0 


0 


0 


0 


0 


0 


0 


0 


Tank 


0 


0 


0 


0 


0 


0 


0 


0 


0 


Neu.Gnd 


0 


0 


0 


2 


0 


0 


0 


0 


0 


Pt Boat 


0 


3 


0 


0 


0 


0 


0 


0 


0 


Sub 


0 


0 


1 


0 


0 


0 


0 


0 


0 


Neu. Sea 


0 


1 


0 


0 


0 


0 


0 


0 


0 


ASCM 


6 


0 


0 


0 


0 


0 


0 


0 


0 


Hold 


0 


0 


0 


0 


0 


0 


1 


0 


0 


Silk Air 


6 


0 


0 


0 


0 


0 


0 


0 


0 



Table 3: Task attribute vector values, the attributes for medivac capability (0 for all tasks except 
Medivac) and identification as an enemy (1 for enemy, 0 otherwise) were deleted from the table. 



2. Prerequisites 

Despite the desire for experimental control, the experiment was designed to allow 
variance in task structure execution at the unit level in order to accommodate differences 
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in organization structures and teams during the experiment trials. Player teams were given 
latitude in the execution of tasks by providing them multiple decision points with 
multiple options to complete tasks. Some resources used in an attack might induce errors 
or result in nonoptimal resources used in an attack, particularly involving the coordination 
events, e.g., the players’ decisions regarding resource utilization coupled with the ten 
second window for coordinated attacks, time pressure, and other constraints. As a result, 
prerequisites leading to coordination events tended to be “hard” (see definition of 
hard/soft prerequisites in Chapter II), and prerequisites within the coordination events 
themselves tended to be “soft”. 

E. SCENARIO DEVELOPMENT 

The scenario for the second experiment was adapted from the scenario used for 
experiment one and the joint officer interviews (Berigan, 1996/Alphatech, Inc., 1995). 

The goal was to design three variants of the same scenario, two to be used as training 
sessions without triggers and the other as the actual experimental scenario, including two 
vignettes within the experimental scenario to serve as trigger events that injected changes 
in mission or resources. The triggers were designed to induce organizations to adapt their 
organizational structure. The training and experimental scenarios were similar in format, 
but the training scenarios presented a significantly lighter workload for the DMs. This 
was to allow the players time to learn the “knobology” of the DDD simulation, train as a 
team, ask questions concerning the scenarios, and practice all the techniques necessary to 
operate in the DDD environment. Examples of all functions to be encountered in the 
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trials were included in the training scenarios to reduce training effects. No trigger events 
were introduced in the training scenarios. 

After the experimental scenario design was completed, a detailed decomposition 
of the mission and resources was completed resulting in a detailed task graph. This effort 
produced the inputs required by the modelers at UCONN for developing the model-based 
organizational structure. Inputs required by the modelers included such items as: 

• A list of tasks with sequencing, including total number of occurrences in 
the scenario and the probability of occurrence during each phase of the 
mission. See Tables 4a and 4b and Figure 3 for details. 

• Resources available. 

• Resource capabilities. 

The two organizations used in the experiment to complete the mission were 
designated TA (NPS’s structure that was manually derived using current military 
methods) and NTA (UCONN’s structure that was model-based). These structures and 
how they were designed will be described later in this chapter. 

After the experiment scenario was developed and resource allocation completed 
for each of the organizational structures, the scenario was converted into 
OPERATIONAL ORDERS (OPORDs) and the vignettes containing the trigger events 
were converted to ORDER MODIFICATIONS (ORDMODs) for each predetermined 
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Task 


Obstacle 1 


Obstacle 2 


Obstacle 3 


Obstacle 4 


Obstacle 5 




Prob. 


Qty 


Prob. 


Qty 


Prob. 


Qty 


Prob. 


Qty 


Prob. 


Qty 


Artillery 


L 


3 


H 


3 


H 


3 


H 


10 


H 


10 


Frog Lncher 


L 


2 


H 


2 


H 


2 


H 


5 


H 


5 


Silkworm 


L 


1 


H 


1 


H 


1 


H 


3 


H 


3 


Mine Land 


0 


0 


M 


1 


M 


1 


M 


2 


M 


2 


Mine Sea 


0 


0 


H 


1 


H 


1 


H 


0 


H 


0 


Strike Air 


L 


1 


L 


2 


L 


2 


L 


3 


L 


3 


Tactical Air 


L 


1 


L 


1 


L 


1 


L 


2 


L 


2 


Helicopter 


L 


1 


L 


1 


L 


1 


L 


2 


L 


2 


Neutral Air 


H 


2 


H 


2 


H 


2 


H 


10 


H 


10 


Tanks 


0 


0 


M 


1 


M 


1 


M 


2 


M 


2 


Neutral Grd 


M 


1 


M 


1 


M 


1 


M 


3 


M 


3 


Patrol Boat 


L 


1 


H 


1 


H 


1 


H 


3 


H 


3 


Submarine 


L 


1 


M 


1 


M 


1 


M 


3 


M 


3 


Neutral Sea 


M 


2 


H 


2 


H 


2 


H 


10 


H 


10 


Medivac 


0 


0 


M 


1 


M 


1 


M 


2 


M 


2 


Swamp 


H 


0 


H 


- 


H 


- 


H 


- 


H 


~ 


Hold 


L 


0 


L 


0 


L 


0 


L 


1 


L 


1 


Silkworm 


H 


1 


H 


1 


H 


1 


H 


3 


H 


3 


Air 























Table 4a. Task Occurrence Probability and Quantity Inputs 
Table Codes: H - High probability of occurrence (1.0) 

M - Medium probability of occurrence (.6) 

L - Low probability of occurrence (.3) 

0 - Zero probability of occurrence 

~ - Does not occur on roads, full coverage of areas around roads 
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Task 


Defend 1 


Defend 2 


Defend 3 


Defend 4 


Defend 5 


Defend 6 


Defend 7 




Pro 


Qty 


Pro 


Qty 


Pro 


Qty 


Pro 


Qty 


Pro 


Qty 


Pro 


Qty 


Pro 


Qty 




b 




b 




b 




b 




b 




b 




b 


Artillery 


0 


0 


0 


0 


H 


15 


H 


15 


H 


15 


H 


3 


H 


3 


Frog 

Lncher 


0 


0 


0 


0 


H 


10 


H 


10 


H 


10 


H 


2 


H 


2 


Silkworm 


H 


10 


H 


10 


0 


0 


0 


0 


0 


0 


0 


0 


0 


0 


Mine Land 


0 


0 


0 


0 


0 


0 


0 


0 


0 


0 


0 


0 


0 


0 


Mine Sea 


L 


0 


L 


0 


0 


0 


0 


0 


0 


0 


0 


0 


0 


0 


Strike Air 


H 


3 


H 


3 


H 


3 


H 


3 


H 


3 


H 


1 


H 


1 


Tactical 

Air 


H 


3 


H 


3 


M 


1 


M 


1 


M 


1 


M 


1 


M 


1 


Helicopter 


H 


3 


H 


3 


H 


2 


H 


2 


H 


2 


H 


2 


H 


2 


Neutral Air 


H 


8 


H 


8 


H 


4 


H 


4 


H 


4 


H 


4 


H 


4 


Tanks 


0 


0 


0 


0 


H 


2 


H 


2 


H 


2 


H 


1 


H 


1 


Neutral 

Grd 


0 


0 


0 


0 


H 


3 


H 


3 


H 


3 


H 


2 


H 


2 


Patrol Boat 


H 


4 


H 


4 


0 


0 


0 


0 


0 


0 


0 


0 


0 


0 


Submarine ■ 


H i 


2 


H 


2 


0 1 


0 


0 


0 


0 


0 


0 


0 


0 


0 


Neutral 

Sea 


H 


8 


H 


8 


0 


0 


0 


0 


0 


0 


0 


0 


0 


0 


Medivac 


0 


0 


0 


0 


M 


0 


M 


0 


M 


0 


M 


0 


M 


0 


Swamp 


0 


0 


0 


0 


0 


0 


0 


0 


0 


0 


0 


0 


0 


0 


Hold 


0 


0 


0 


0 


H 


1 


L 


1 


L 


1 


H 


1 


H 


1 


Silkworm 

Air 


H 


? 


H 


? 


0 


0 


0 


0 


0 


0 


0 


0 


0 


0 



Table 4b. Task Occurrence Probability and Quantity Inputs 
Table Codes: H - High probability of occurrence (1.0) 

M - Medium probability of occurrence (.6) 

L - Low probability of occurrence (.3) 

0 - Zero probability of occurrence 

? - Occurrence of this item dependent on team performance, task spawned only if 
team fails to properly perform parent task. 
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Figure 3. Overall Mission Task Graph 

initial organizational structure. An OPORD is a narrative providing directions on how the 
overall operation is to be conducted and includes such items as asset availability and 
ownership, tasks to be accomplished, time lines, and intelligence reports. The military 
issues OPORDs to task and provide guidance to the Commander Joint Task Force (CJTF) 
and his subordinate commanders. A copy of the OPORDs and ORDMODs are included 
as Appendix A. Detailed descriptions of the information provided to the players in the 
OPORDs as well as experimental control issues such as scenarios, general situation, 
enemy situation, mission, friendly forces and asset ownership, how the mission will be 
executed by friendly forces, mission, mission priorities, the manner in which the scenario 
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should unfold, and the organizations tested follows. 

1. Scenario Background 

The scenario for experiment two is similar to the scenario for NPS experiment 
one and is abstracted from the OPORD contained in Appendix A. 

The neighboring nation of Yang has attacked the nation of Ying, which is a U.S. 
ally. Attacking forces have succeeded in seizing the Yingian port of Plethora and the 
nearby international airport. The Yingian government has requested U.S. assistance in 
taking back the port of Plethora and driving Yangian forces from Ying (See Figure 4). 

The port of Plethora is protected by obstructions, mines, obstacles, and the 




Figure 4: DDD Area Map 
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presence of hidden enemy among the port facility buildings. Two beaches approximately 
5 miles south of the port are to be the sites of the amphibious assaults. The northernmost 
beach (designated “Red Beach”) has a road leading to the port. The southernmost beach 
(designated “Blue Beach”) has a road leading to the airfield. Waterborne approaches to 
the beaches are/may be mined. There is a hill to the north of Red Beach occupied by an 
enemy heavy mortar platoon with a platoon of infantry for security. This terrain 
dominates both Red Beach and the port. It must be taken and retained for a successful 
attack on Red Beach and the port. At the port, but hidden from view, is a company-sized 
armored counterattack force that can move toward Red Beach in response to any 
amphibious assault. Similar counterattack forces exist at the airfield, which is located 
about 5 miles inland from Blue Beach. These counterattack forces could inflict serious 
damage if not interdicted before they reach either beach. The off-road terrain between the 
beaches, port, airfield, and hill is swampy and treacherous; it is unsuitable for travel. 

Thus, all travel must be on the two roads. Both of the roads may be mined, but locations 
of the minefields, if any, are unknown. The port, airfield, both roads, both beaches, and 
hill are located within range of enemy artillery strong-points which must be suppressed. 
The northernmost strong-point can shoot at Red Beach and the port. The southernmost 
strong-point can shoot at both Blue Beach and the airfield. The artillery pieces are 
housed in reinforced concrete bunkers, with ammunition stored in bunkers deep 
underground. Even concentrated air attacks will not completely disable the artillery 
strong-points. The enemy can wheel out artillery pieces (from 8 to 24 at a time), set up, 
sight in, and fire within 5 minutes. If friendly forces can get effective ordnance on target 
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in less than 5 minutes, the enemy will wheel their artillery pieces back into the bunkers 
and wait until another time. 

Enemy Frog (SCUD-like) Missile Launchers, capable of carrying chemical 
munitions, are hidden in the vicinity of both artillery strong-points. They can emerge 
from covered positions, prepare warheads, and fire missiles within 10 minutes. They 
must be destroyed by an appropriate combination of ordnance. 

The submarine threat to the ARG and CVBG is considerable. Enemy Alfa-class 
submarines are known to be in the area. These submarines must be detected and 
destroyed to protect the fleet. 

The enemy possesses HIND helicopters with the capability of launching anti-ship 
missiles. The CG, DDGs, FFGs, and aircraft possess capabilities to counter these 
helicopters. 

The enemy has significant air strike capability and can launch anti-ship missiles 
from most of its strike aircraft. 

The enemy’s Special Forces possess numerous fast patrol boats that can fire very 
potent torpedoes or be loaded with explosives for suicide missions. These can be engaged 
and destroyed by the CG, DDGs, FFGs, fighters, and Cobras. 

There are Silkworm threats throughout the area. The Silkworm missile launchers 
have been placed in residential neighborhoods because they know the U.S. will be 
reluctant to target residential areas. Accordingly, if U.S. warships want to target a 
Silkworm launcher, they must first get visual confirmation of its presence, using theater 
reconnaissance (RECON) (TARPS) assets, and any strike mission must use precision 
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guided munitions. 

A Joint Task Force (JTF) has been organized by a notional theater commander in 
chief, the CINC, in order to capture the port and airfield to allow for the introduction of 
follow-on forces. The CINC’s ultimate purpose will be to drive Yangian forces from 
Ying and destroy their capability for offensive warfare. The Commander, JTF (CJTF) has 
at his disposal an aircraft carrier, an AEGIS cruiser, two DDGs, two FFGs, two LPDs, 
two LHDs, 10 sections of FA- 18s, 8 sections of AV-8Bs, four sections of Cobras, two 
mine countermeasure helos, two MEDIVAC helos, one TRAP reconnaissance aircraft, 
three AAAV companies, six rifle companies, two Stinger detachments, and two 
engineering platoons. Figure 4 (page 56) gives a representation of the operation area. 

2. Friendly Situation and Assets 

The following groups the assets in generic component task groups or units; the 
DM that will “own” and control each asset during DDD play is dependent on the 
organization structure. (See Figures 5 and 6 for details about organizational structures) 

There are a theater-level Joint Force Air Component Commander (JFACC) and 
other friendly forces conducting independent operations against the enemy in Ying, not 
in concert with the JTF. The presence of these independent friendly units and neutral 
platforms forced the CJTF to identify contacts prior to attacking to ensure friendly and 
neutral forces were not destroyed. The identification process also provided information 
needed by the DMs to assign the right mix of assets to successfully attack a hostile unit 
when appropriate. The aircraft from the CVBG available to support the JTF are the 10 
sections of FA- 18s, 8 sections of AV-8Bs and 1 FA- 18 TARPS aircraft. The FA- 18s with 
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laser guided bombs can attack FROG launchers and confirmed Silkworm (land-based 
anti-ship missile) missile sites, or they can be used for anti-air warfare, and to man 
combat air patrol stations. The AV-8Bs can be used to provide close air support to the 
ground troops. The FA- 18 TARPS can be used for reconnaissance only. 

MEU 1 is composed of one Advanced Amphibious Assault Vehicle (AAAV) 
mounted infantry company, two MV-22 Osprey mounted helibome infantry companies, 
one division of AH-1W Cobra attack helicopters, one division of mine countermeasures 
(MCM) helicopters (indivisible), one engineer platoon, and a division of MEDEVAC 
helicopters (indivisible). MEU 2 is composed of two AAAV mounted infantry 
companies, one V-22 mounted helibome infantry company, one division of AH-1W 
Cobra attack helicopters, one division of mine countermeasures (MCM) helicopters 
(indivisible), one engineer platoon, and a division of MEDEVAC helicopters 
(indivisible). Each MEU will be considered to have an unmanned aerial vehicle (UAV) 
flying in its support for the duration of the operation. The players will not control the 
UAVs but their presence will be represented by the nearly omniscient battlefield picture 
each MEU will possess. 

As mentioned previously, the assets were designed so that single assets could not 
successfully accomplish a coordination event task; coordination was required to assign 
multiple assets to achieve the right mix for a successful attack. Various combinations of 
assets are capable of accomplishing each coordination task. Single assets could make 
repeated attacks on a target, but in this experiment, DDD-HI would assign a penalty and 
the attacking unit would not be assured of destroying the target. This was done to force 
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coordination where the experimental designers wanted it to occur. 

The asset-to-task matching was implemented on DDD-in via specification of task 
resource requirements and asset resource capability. Each task and asset is associated 
with a 9-dimension resource vector R = (rl, r2, ... , r9) as shown in table 2, with 
components that correspond to task requirements or combat capability/potential in 
various categories (r/s) For example, rO = air combat, rl = sea combat, ..., r6 = 
holding/occupying, r7 = sea mines, r8 = land mines, r9 = medivac. Assigning a set of 
values to R for a specific task (see Table 3) establishes what mix of assets, with their 
corresponding sum of R values, is sufficient to correctly process that task. Thus, 
mine-clearing helicopters have relatively high values assigned to r7 corresponding to the 
combat potential of that unit for sea mine tasks. Other assets with other primary 
capabilities would have lower values assigned to r7, or zero (Kemple, et al., 1996). A 
coordination event such as taking a beach would require sufficient values in the q 
elements for ground assault, armor, and hold that could not be satisfied by any one asset 
but could be satisfied by several different combinations of assets. The R values of all 
assets assigned to attack a task are totaled within each r s to determine whether the 
assigned units have sufficient collective combat potential to complete the task. If the 
combined R values of the assigned assets are greater than or equal to each component of 
the R values of the task, the team is credited with a successful attacks without losing 
points. If the combined R of the assigned assets are less than R of the task in any 
component (inadequate attack), the target is destroyed but the team is penalized a 
predetermined number of points. If assets with collective r,’s = 0 in required combat 
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potential areas are assigned (an inappropriate attack), the target is not killed and the team 
again loses points. 

A summary of the assets available and assigned owners is shown in Table 5. The 
combat potential for each asset is shown in Table 2. Penalty points are levied in a binary 
fashion; either the task is completed successfully and no points are deducted or it is not 
and the maximum penalty points are deducted. 

3. Mission 

In order to successfully complete a trial, a set of coordination and background 
tasks must be completed in priorities and sequence within 40 game minutes. The CJTF 
and his subordinate commanders (the team participating in the trials) must accomplish the 
following: 

Ground Component: To secure the port and airfield of Plethora, allowing for the 
introduction of follow-on forces. In order to achieve these objectives, enemy forces and 
defenses must be identified, engaged and defeated. 

Maritime Component: To support the amphibious operation with close air 
support (CAS), naval surface fire support (NSFS), mine countermeasures, and air defense 
and medivac assets, and to defend the CVBG and ARG from air, surface, and subsurface 
threats. 

The specific DM-to-task assignment is dependent on the organizational structure 
and assignment of resources. 
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Platform 


Owner in TA 


Owner in NTA 


Total Qty 


DDG 


DM 1/DM 3 (1 ea) 


DM4 


2 


FFG 


DM2 


DM5 


2 


CG 


DM2 


DM4 


1 


CV 


DM2 


DM0 


1 


LSD 


DM3 


DM4 


1 


LHA 


DM 1 


DM5 


1 


LPD 


DM 1/DM 3 (1 ea) 


DM 4/DM 5(1 ea) 


2 


Eng Pit 


DM 4/DM 5(1 ea) 


DM 4/DM 5(1 ea) 


2 


Rifle Company 


DM 4/DM 5 (3 ea) 


DM 1/DM 3 (3 ea) 


6 


Stinger Detachment 


DM 1/DM 3(1 ea) 


DM 1/DM 3 (lea) 


2 


Cobra Section 


DM 4/DM 5 (2 ea) 


DM 2/DM 3 (2 ea) 


4 


CAS Section 


DM2 


DM0 


8 


Fighter Section 


DM2 


DM5 


10 


Huey Med 


DM 1/DM 3 (1 ea) 


DM 4/DM 5(1 ea) 


2 


MCM Huey 


DM 1/DM 3 (1 ea) 


DM 4/DM 5(1 ea) 


2 


RECON Aircraft 


DM0 


DM0 


1 


AAAV 


DM 4(2)/DM 5(1) 


DM 1 (2)/DM 3(1) 


3 


MV-22 


DM 4( 1 )/DM 5 (2) 


DM 1(1)/DM 3 (2) 


3 


Table 5: Assets, owners, and 


quantities of each available 
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Figure 5: Traditional Architecture 



4. Execution 

Each MEU simultaneously lands an AAAV-mounted company on the beach. 
MEU 1 attacks Red Beach, and MEU 2 attacks Blue Beach. MEU 1 simultaneously 
secures the commanding terrain overlooking Red Beach and the port with its helibome 
company. Once the beaches and commanding terrain are secure, the two AAAV-mounted 
companies proceed down the roads from their respective beaches, clearing minefields 
with the engineer platoons, killing counterattack forces with the Cobras, and conducting 
MEDEVACs as necessary. 
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Figure 6: Nontraditional Architecture 



Each MEU has an unmanned aerial vehicle (UAV) (launched from the ARG) 
airborne for the duration of the operation. The UAVs keep the artillery strong points and 
the suspected FROG sites under constant surveillance, so that NSFS or CAS assets can be 
brought to bear immediately if they are needed. 

Once the roads have been cleared, the AAAV-mounted companies from MEU 1 
and MEU 2 attack the port and the airfield, respectively. MEU 2’s AAAV-mounted 
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company is joined in its attack by a helibome company from MEU 2. It is important that, 
once the AAAV-mounted companies land on the beach, the airfield and port be taken as 
quickly as possible, before the enemy has a chance to organize his defense and send 
reinforcements. It is desired that final assaults on the airfield and port be conducted 
simultaneously, in order to present the enemy commander with the most confusing, 
dilemma-filled environment possible, but if one attack must be conducted before the 
other, the airfield takes priority. If the airfield attack is held up for any reason, the port 
attack should wait to retain the synergism of concurrent attacks; if the port attack is held 
up, the airfield attack should go forward. 

Due to hydrographic limitations, the ARGs and the CVBG have to be significantly 
separated during the operation, enough to preclude them from being under a joint air 
defense umbrella provided by the AEGIS cruiser. Thus, the AEGIS cruiser should remain 
with the CVBG, but position itself so that it can rapidly move from the CVBG to the 
ARG if that becomes necessary. Additionally, the two destroyers are to be inshore, 
providing NSFS support, while the frigates are the primary anti-submarine warfare 
platform for the CVBG. The frigates performing anti-submarine warfare should, like the 
AEGIS cruiser, position themselves so that they can quickly move to support the ARG if 
that is necessary. 

The ARG launches the Marines for the initial assault on Red and Blue Beaches. 
The ARG will launch the mine countermeasures helicopters. Cobras, MEDEVAC 
aircraft, the air assault for MEU 2’s attack on the airfield, etc. when called to do so. The 
destroyers will provide NSFS to suppress the artillery strong points ashore when 
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requested to do so by either of the MEUs. 

The CVBG is to keep two sections of FA- 18s with precision guided munitions on 
standby at all times: one to be used against FROGs (in support of the MEUs) and the 
other against Silkworms (in support of the CVBG or ARG). The CJTF will be launch 
authority for both sections. The CVBG is to also provide two sections per hour of air 
defense aircraft (FA- 18 or F-14), with one combat air patrol station over the CVBG the 
other over the ARG. 

If a suspected Silkworm launcher is detected, it must be identified first by the FA- 
18 TARP before it can be destroyed. A Silkworm launcher detected at the northernmost 
site threatens the CVBG, at the southernmost site, the ARG. 

5. Priorities 

The JTF’s overall priority, and the priority within the ground component, is MEU 
2’s attack on the airfield, because the initial buildup of friendly forces can be most 
quickly and effectively achieved through air transport. 

The following CJTF’s priorities were given to the players within the maritime 
component: if both the ARG and CVBG are threatened by the enemy, the ARG has 
priority of support against submarine threats, fixed-wing air threats, and patrol boats. If 
there is a threat of an air attack against the ARG, the ARG should get the AEGIS cruiser 
and a combat air patrol. 

The frigates, performing anti-submarine warfare, and the AEGIS cruiser, 
performing anti- air warfare, stay with the CVBG unless a necessity occurs with the 
ARG, because the CVBG is considered a more likely target for the enemy. The CVBG 
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has priority against land-based Silkworm sites and helicopters. 



F. DEVELOPMENT OF THE TRAINING SCENARIOS 

In order to familiarize the subjects with the general situation in the scenario and 
the DDD III simulation (the operational context and activities required such as requesting 
assets, communicating using voice and preformatted message sets, et cetera), I created 
two training scenarios based on the experimental scenario. The training scenarios were 
identical to the experiment scenario, except they did not contain as many coordination 
events, as high a workload, or trigger events. 

1. Development of Organizational Structures 

The design of the experiment required two organizational structures to test the 
hypotheses. One, called the Traditional Architecture (TA) was designed based on military 
principles, the other organizational structure was provided by the modelers at UCONN 
and was based on minimizing coordination between DMs (external coordination). 

Transfer of assets between DMs was not allowed. This organizational structure was called 
the Nontraditional Architecture (NT A). The organizations are structurally different, yet 
logically and efficiently designed. 

a. Traditional Architecture Organizational Structure 
The TA organizational structure developed at NPS was based on the 
principles for force structure organizations delineated in Joint, Service, and Component 
Doctrine. The principles were: 

1. Design the organization structure in a way that clearly defines the structure of 
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authority, responsibility, and ownership of assets, establishing a network of relationships 
among commanders delineating communications channels, chain of command, authority 
and responsibility, and unity of command. 

2. Provide framework for building task forces and task groups. 

3. Provide a reasonable span of control (varies with each situation) 

“. . . command and control organizations must be able to handle and 
disseminate information efficiently. We generally favor more 
decentralized organizations, which can process information more quickly, 
to maintain a high tempo of operations. ’’(Marine Corps Doctrine 
Publication 6, 1996) 

4. Provide Unity of Effort: Unity of effort implies ...“that all the participants in an 
operation strive to shape their efforts toward a common goal. It does not imply rigid, 
centralized control, but rather cooperation, coordination, and mission control. ’’(Naval 
Doctrine Publication 6,1996) 

5. Provide Simplicity of communications - Fully connected (open) 
communications between nodes does not constrain the design of task organizations or 
adaptation. 

6. Provide Economy of force - Economy of forces means that the minimum 
quantity of personnel, equipment, and other necessary resources are committed to the 
mission to ensure overwhelming force can be applied. Economy of force minimizes the 
cost of the mission in terms of casualties and damage during the mission and in monetary 
terms. 
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7. Organize and control battle space and manage information. 

Other factors that influenced the selection of the organizational structure were 
pattern matching, history, and past experiences. Pattern matching refers to the aspect of 
humans to look for similarities or patterns between a current problem or situation and 
previous experiences, and then tailor the solution for that problem to the present one. 
Figure 7 shows the organizational structure and ownership of assets for the traditional 
organization. (Figures 7 and 8 are replicates of Figures 5 and 6, placed here for the 
readers convenience) 

In Figure 7, the TA organization, DM 0 would be equivalent to the CJTF with 
overall responsibility for the operation. DMs 1 and 3 would equate to ARG 1 and 2 
respectively. DM 2 would be the carrier battle group commander, providing air support 
for the operation, the joint force air component commander (JFACC), and handling the 
duties of the maritime component commander (MCC). DMs 4 and 5 would be the MEU 1 
and 2 commanders. 
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Figure 7: Traditional Architecture (same as Figure 5, provided here for convenience) 



b. Nontraditional Architecture Organization Structure 
In order for the UCONN modelers to design an organizational structure 
based on the mission, they needed detailed information about the mission, tasks, task 
structure, probabilities of encountering each task/subtask, assets, and asset capabilities. 
The models then used to design an organizational structure and assign asset ownership to 
the structure based on expected/probable tasks such that workload between 
DMs would be evenly distributed and minimum coordination would be required between 
nodes. Figure 8 shows the organization structure and ownership of assets for the 
nontraditional organization. In the NTA organization, DM 0 would again equate to the 
CJTF, but the other DM’s do not fit any of the current military component terms; they are 
unique in their structure. 



72 




c. Differences Between The Traditional and Nontraditional 

Architectures 

Figures 7 and 8 show the command relationships between the DMs in the 
TA and NTA organizations. At first glance, the architectures do not seem to be 
significantly different. Closer examination of the NTA structure shows that “jointness” of 
the organization has been pushed to the next lower echelon in the chain of command 
when compared with the TA structure. This is similar to current military thinking. Recent 
technology advances are obviating much of the interoperability problem in 
communications between the services, permitting joint operations commands to be 
inserted into lower echelons of joint operations while also permitting flattening of the 
organizational structure, thus increasing the overall responsiveness of the command. 

2. Total Asset Determination 

To eliminate another factor in the design of the experiment, both organizations 
(TA and NTA) were assigned the same number of units and platforms, with the same 
combat potential, to achieve the same tasks and complete the mission. We desired to 
ensure sufficient resources with associated capabilities were provided to the organizations 
to accomplish the mission before and after the triggers and to ensure that both 
organizations were required to coordinate both internally and externally. Therefore, it was 
necessary to perform an iterative process, closely integrating asset design with the 
scenario and trigger design efforts to determine the proper quantities and capabilities of 
the assets. It was necessary to define/refine platform resource vectors and task attribute 
vectors (Explained before) to: 



73 



1. Require coordinated action by two or more units/platforms to accomplish 
mission tasks. 

2. Ensure that more than one combination of platforms could be used to 
accomplish mission tasks. 

3. Ensure sufficient assets were provided to accomplish missions before and after 
the triggers were invoked. 

4. Organize task forces into capable subordinate elements. 

5. Organize overall mission into manageable parts. 




Figure 8: Nontraditional Architecture (same as Figure 6, provided here for convenience) 
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G. 



CONDUCT OF EXPERIMENT 



An overview of the experiment including the facilities, equipment, lead team, 
players, and training is provided in this section. Most of the equipment and facilities were 
the same as used in experiment one. 



1. Experiment Setup 

The second NPS A2C2 experiment was conducted in the secure Systems 
Technology Lab. 

a. Physical Facilities 

The scenario was presented to the player teams on a distributed, 
interactive, computer simulation running on seven SUN SPARC™ model 20 
workstations (one for each of the six DMs and one for the DDD-III controller’s station). 
The Systems Technology Laboratory at the Naval Postgraduate School in Monterey, CA 
was utilized for conducting the experiment. It provides an area where access is controlled 
so interrupts and disturbances are minimized. Although all players from a team were 
located in the same room, dividers were placed between them to physically obstruct their 
views of the other players’ screens. Communication among players was restricted to 
preformatted computer messages built into the simulation and recorded voice 
communications over two separate channels connected to common headsets. The ability 
to communicate between DMs is an important factor affecting organizational structure 
and coordination of efforts. DM nodes in an organizational structure represent the 
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decision makers or commanders of the resources that are responsible for completing 
assigned tasks in the overall mission. For the purposes of the experiment, “stovepipe” C4I 
systems have been eliminated in the scenario and all DMs easily communicate with each 
other by voice or electronic messages. 



b. Lead Team 

A group of nine NPS officer students from the Joint C4I Systems 
Curriculum in their last year were designated as the “lead team” for this experiment. The 
lead team was composed of officers from all four branches of the armed forces. In 
addition, all members had recent operational experience. Since I had been involved as an 
associate researcher on the A2C2 project for the past year, I headed the lead team. 

The lead team performed such tasks as preparation of training materials for 
the subjects, conduct of subject training, setup of the physical space, debugging the 
simulation, piloting the scenario’s implementation in the simulation, conduct of the 
experimental runs, and data collection. The lead team members provided invaluable 
suggestions and advice concerning all of the above tasks, developing the scenario, and 
filled many gaps in the author’s experience. 

c. Test Subjects Used 

The test subjects were 23 military officer students from the Joint C4I 
Systems and Space Systems Operations Curricula plus a recent graduate from NPS. The 
subjects were organized into six four-person teams with two confederates rounding the 
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teams up to six. The confederates were three members of the lead team who augmented 
the player teams. The confederates were used to perform the functions of one of the DMs 
at each of the two lowest echelons. By using the confederates, we were able to form six- 
player teams from the 24 subjects. The teams were formed by the experimenters with 
participants distributed according to military occupational/war fighting specialty and 
branch of service, to the extent that was possible given the demographics of the sample. 
Table 6 shows the composition of the teams by branch of service, type of service 
(operational or support), and curricula Since there was a fairly significant difference 
between the operational experience of the subjects, the experimenters were concerned 
that some subjects would be more familiar than others with the appropriate tactics to 
employ in a given situation, and that this might bias the performance measures chosen as 
dependent variables. In order to help protect against such an effect, the scenario and the 
operations orders were tailored to facilitate a step-by-step approach to each situation. 
This approach further aided the experimenters’ attempt to steer the subjects toward the 
coordination events that were of primary interest in the experiment. 

d. DDD-1II Simulation 

The experiment was conducted using the Distributed Dynamic • 
Decisionmaking-IH (DDD-IH) paradigm simulation. Earlier variants of the DDD had 
been used extensively to study decisionmaking in the Navy’s Composite Warfare 
Commander (CWC) organizational structure and civilian sector organizational 
experiments. Last year DDD was extended to fit the general requirements of tier-I 
experimentation for the A2C2 project, and was further enhanced to meet the specific 
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requirements of the current experiment. DDD is not a tactical model on the level of 
RESA, JTLS, MTWS, CBS, or AWSIM which are driven by extensive and detailed 
parametric databases. DDD is a more abstract game that uses performance and resource 
vectors to describe entity capabilities at a higher level of abstraction. The result is a 
simulation that appears to operate like the combat event simulations above, but is easier 
to use to develop scenarios and requires a much shorter time to train subjects. DDD-1H 
contains data collection and variable manipulation capabilities that make it very 
appropriate for a research environment. For a more detailed explanation of DDD-IH, 
including characteristics, see Higgins (1996). 
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Legend For Table 


Code# 


Factors 


Meaning of Codes 


1 


Branch of 
Service 


N = Navy A = Army F = Air Force M = Marine 

Corps 


2 


Type of 
Service 


0 = Operational S = Support 


3 


Curricula 


C = C4I S = Space Systems Operations 0 = Ops 
Research 



Table 6. Composition of the Teams of Players for the second NPS Experiment 



e. Matching of Subjects to Task/Organizational Structure 
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The research team wanted to assign the subjects to a particular node at 
each level of hierarchy in the organizational structures throughout the training and data 
runs; if a subject began the training runs as the CJTF for his team, for example, he would 
remain CJTF throughout the experiment. In addition, it was desired to keep the subjects 
involved at each level in of the hierarchy in the organizational structures. To facilitate this 
requirement, the confederates were assigned to DM 1 and DM 5 nodes in the traditional 
organization and to DM 1 and DM 4 nodes in the nontraditional organization. 

To the greatest degree possible, the experimenters and lead team attempted 
to match the subjects to positions in the organizational structure for which they had some 
operational experience. 

2. Operationalization of Task/Organizational Structures 

The organizational structures and the task structures were operationalized in three 
significant respects: asset structure, communications structure, and information structure. 

a. Asset Structure 

The scenario was designed so that some tasks (coordination events) could 
not be successfully performed with a single asset. The assets required to perform a task 
requiring a coordinated attack may belong to one or more DMs. Unlike experiment 1 , 
assets could not be transferred between DM’s in this experiment. Instead the DM 
initiating the attack must coordinate the attack with resources he owns or he must 
coordinate with other DMs to successfully perform the task. For example, if MEU 2 was 
attacking the beach and required support, the experimenters wanted MEU 2 to request 
support from the necessary asset (the DDG) to shell the beach, rather than allowing the 
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DM owning the DDG to transfer it to MEU 2. This was enforced by DDD-DI to ensure 
that the external coordination events actually occurred. Table 2 shows each platform’s 
resource or combat potential vector and the task attribute vector (enemy force combat 
potential) required for a successful attack. 

b. Communications Structure 

Communications in this experiment consisted of preformatted messages 
and data transfer using the DDD-III simulation and two channels of open voice 
communications. Open communications were allowed between all DMs, simulating the 
projected future integrated C4I systems ability to provide a common operational picture 
(COP) as described in the next section. 

Copies of all messages sent by a decisionmaker were automatically 
forwarded to the next higher level in the sender’s hierarchy. If a lower-level unit 
communicated with another low-level unit, copies of the messages were automatically 
sent to the intermediate commander in his chain of command. If the intermediate level 
commander communicated with a lower level unit, a copy of his message was 
automatically forwarded to the CJTF. 

Both voice channels were open so that all DMs could monitor all 
communications. The recommendation to the subjects was to have one channel for all 
routine communications and the other channel be used by DMs who were coordinating an 
attack. 

c. Information Structure 
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One of the major assumptions for this experiment is the existence of a 
common operational picture (COP) and a fully integrated communications network which 
allows all commanders at all levels to have a common view of the battlespace; they see 
the same threats, at the same time and can easily and readily communicate up, down, and 
across the chain of command. Since our purpose was to test organizational structures in a 
future environment of shared, global information, the COP was implemented in our 
experiment. When one decisionmaker in the organization saw a threat or task, others saw 
it too. To provide identification of a target, the DM whose sensors held the contact had to 
fuse that information into the COP by sending it to the other DMs. 

3. Training 

The proper training of the subjects in the operation of the simulation and the 
requirements of the operations order (OPORD) was vital to the success of the data runs. 
Two aspects of this training were significant: the training materials that the lead team and 
experimental team generated, and the conduct of the training itself. 

a. Training Materials 

Three primary training aids were developed for the experiment: an 
operational order (OPORD) which transformed the scenario into a directive for execution 
of the operation, a tutorial designed to aid the subjects in using the DDD-III, and the 
scenario developed for the training portion of the experiment. 

(1) Operations Order: When a military operation or exercise is conducted, 
an OPORD is issued as a directive listing mission requirements including resources, 
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threats, constraints, and options. This OPORD provides the unit(s) that will conduct the 
mission the general situation, enemy forces, friendly forces, assets available, the mission 
requirements, how the mission will be executed, logistics, and command and control 
information. This was the format used to provide the subjects the information needed to 
execute the scenario. 

(2) Tutorial: The tutorial provided the link between the OPORD and 
DDD-IH. It described the simulation, its display and user interface, functions of the 
mouse, requesting, launching, moving and transferring assets, identifying and attacking 
threats, and use of the communications system to view, send, and receive messages. The 
tutorial listed and described in detail the objects that appear on the DDD-EH screen, 
including terrain features, and provided a description of the organization structures used 
in the experiment and how they are implemented in DDD-IH. A quick reference sheet 
was provided that concisely described all the objects on the screen and possible asset 
combinations that could be used to destroy enemy threats, abbreviations used by DDD, a 
list of assets, and the platforms on which they were carried. 

(3) Training Scenarios: The training scenarios were devised to help the 
subjects learn about the simulation and OPORD, and allow them to become proficient in 
the skills that would enable them to successfully complete the mission and coordination 
efforts during the trials. The experimenters did not want to overload the subjects during 
the training phase, so the training scenarios were devised with a lighter workload. These 
scenarios were written by the author, with advice and assistance from the lead and 
experimental teams. Two scenarios were provided so that the players could not anticipate 
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upcoming tasks and events in the actual trial runs and preposition assets to accomplish 
them. 



b. Conduct of Training 

Initially, the subjects were given a one-hour briefing in a classroom so they 

understood: 

• They were taking part in an experiment (no experimental objectives or 
other compromising details were divulged). 

• The OPORD and the organization structures they were assigned; teams 
were assigned organizational structures, TA or NTA. Teams were briefed 
separately for experimental control purposes. They did not know there was 
any difference in the organizational structures they were assigned. 

• The DDD-IH simulation. 

The purpose of this brief was to give the subjects only a general overview 
of what they would be doing during the training periods and the experiment trials and to 
give them some context for the training runs. The training runs were then conducted as 
previously mentioned, using the training scenarios which contained no trigger events, but 
in aggregate, had a requirement for all of the subjects to use all the assets within each 
component. During the training runs, four members of the lead team were present to 
assist each team of subjects in familiarizing themselves with the simulation and 
OPORDER. The training runs were also used by the research team members for training 
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the lead team observers. The training was conducted in two one-hour blocks, running 
each team through two different scenarios. During the first training session the observers 
and confederates provided instruction to the teams, stopping game time as needed. During 
the second hour of training, to more closely prepare teams to deal with the pace of 
activities during the trials, game time was not stopped. 

4. Experiment Setup 

The experiment was conducted during 12 to 22 November 1996. Observer and 
confederate training was conducted to prepare the lead team-members for their parts in 
the experiment and re-familiarize them with the DDD simulation. The observers were to 
monitor team performance during the trial runs, provide buttonology assistance to the 
players as necessary, control the video recorder, act as DDD-III simulation controllers, 
and take notes to help evaluate team performance and communications. Observers were 
also used during the planning sessions to distribute and collect the data packages, keep 
the teams focused on the planning process, and run the video recorder. They were also 
available to answer any questions the teams had about the requirements and data 
collection questionnaires. 

The confederates assisted the players in training during the first training run, then 
acted as regular members of the team. 

The experimental trials consisted of three two-hour blocks for each of the teams. 
Each team completed the two training runs described above during the first time block. 
The second time block consisted of the first trial run and a “planning session”, in which 
the teams were asked to evaluate their assigned organizational structure (TA or NTA) and 
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propose any organization structural changes they wished to make which would improve 
their ability to complete their mission more effectively. The third time block consisted of 
two one-hour planning sessions. At the start of the hour, the teams were presented with 
one of the two ORDMODs; a NEO which either adds another mission and set of tasks to 
accomplish in addition to the current mission, with the same resources, or a loss of 
approximately one-third of the resources to accomplish the same mission. The teams 
reviewed their ORDMOD trigger, then developed an organizational structure they would 
use to conduct the mission. 

Data was collected during all three runs of the DDD simulation by the lead team 
observers and the members of the experimental team. The two training runs in the first 
time block and the data collection run were each 40 minutes long. The remaining three 
hours per team were used as planning sessions and survey and interview periods for the 
subjects. These periods were used by the lead team and other observers to collect data 
from the sessions. At least three members of the lead team, in addition to the lead team 
confederates, were present at all times during the six hours of training, trials, and 
planning sessions to monitor the subjects, take observation notes and collect data. 

H. SUMMARY 

How the task design process described in Chapter III was implemented for the 
second NPS experiment is described in this chapter. First, the experimental designers 
determined the task structure dimension of interest and required structural characteristics, 
similar to the tasks used in the previous experiment and research. Next, I iteratively 
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developed a scenario, using the task structure description paradigm generated in Chapter 
EH, that complied with the experimental designers’ requirements. This was done within 
the constraints of the dimensions of task structure defined in Chapter II. The 
organizational structures used in the experiment were then developed and checked to 
verify structural differences, and OPORDs and ORDMODs were written. Finally, the 
conduct of the experiment was described, including a closing discussion of the scenarios 
and organizational structures that I helped design. 

Chapter V will include a brief overview of some of the preliminary findings from 
the data. Chapter VI will contain a discussion of the lessons learned from the experiment 
with regard to scenario design, and from the above implementation of the scenario design 
process, as well as some of the modifications and improves to the DDD-III simulation. 
Chapter VII will be a summary of the issues discussed in this thesis. 
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V. PRELIMINARY FINDINGS 



Preliminary analysis of the data from NPS experiment two provided some interesting 
results. This is beyond the scope of my thesis, but an overview of findings based on 
preliminary data analysis by members of the NPS research team provides continuity and 
background for future research areas that I mention later in Chapter VII. 



A. DATA 

Data was collected from various sources and through different methods; this would 
provide a limited cross check on data despite the small sample size available. Data was 
collected through use of the DDD simulation, observers from the lead and research teams, 
video recordings, and questionnaires completed by the players. The data that was collected 
consisted of: 

DDD log files - Files from the DDD-IH simulation recording actions by each 
DM during the DDD-III runs. 

Organizational Charts (command, communications) - These are charts and 
graphs developed by the players during the planning sessions which delineated the chain of 
command and communication connectivity that would exist in their proposed organizational 
structures. 

Asset ownership, functional allocation - Developed by the players during the 
planning sessions to describe the physical structure of their proposed organizational structure. 

Preliminary task graphs - Developed by the players during the second and 
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third planning sessions (sessions with triggers) to explain their intentions and plans for 
completing the mission as modified by the trigger events. 

Post-planning questionnaires - Completed by the players at the end of each 
planning session to solicit additional information from the players about their evaluation of 
the effectiveness the organizational structures and adaptation. 

Observer data - Notes taken by the observers evaluating team and player 
performance during the DDD-III runs and the planning sessions. 

Video tapes of the DDD runs and planning sessions - Video recordings of the 
DDD-III runs and the planning sessions were taken. The videos of the DDD-III runs provided 
a copy of the voice communications. The videos from the planning sessions provide the 
research team with an unobtrusive method of observing the thought processes of the teams 
during the planning. 

B. PRELIMINARY FINDINGS 

The following overview of preliminary findings is not official and is biased by my 
personal thoughts and observations from the experiment. The final findings of the entire 
research team after completing a detailed analysis of all the data and modeling evaluations 
may be significantly different. 

After the training and trial runs on DDD, the teams were given the opportunity to 
change their organizational structure to perform the same mission. Teams were given a 
structured planning sheet and their initial organizational structure as the starting point. 
Although no team kept their initial organizational architecture as played on DDD, no team 
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started from scratch. Instead they all “edited” their starting architectures (TA or NTA) to 
design their new organizational structure. All teams made incremental changes to 
architectures that they were apparently “comfortable” or familiar with. 

• The three traditional architecture (TA) teams submitted hierarchical (3-Level) 
architectures that were essentially a “pruned” traditional structure, while the 
three nontraditional architecture teams submitted flat (2-Level) architectures 
derived from their starting architecture. Although the teams were instructed to 
design a six node architecture, after trigger two, four of the six teams wanted 
organizations with less than six nodes. 

In order to determine if these are “results” or just artifacts, a more complete 
analysis is in progress. 

• While both organizations had a similar workload at the DM 0 level, the 
traditional architecture generally outperformed the nontraditional architecture 
on mission performance subtasks, with “mission” scores averaging 96% 
versus 85.3% even though the nontraditional architecture required (and 
showed) fewer inter-DM coordinations on mission performance subtasks. 

• The traditional and nontraditional architectures performed about the same 
overall on defend and encounter tasks. These invariably were done by a single 
DM in both organizations. 

• The traditional architecture was better at suppressing ground threats while the 
nontraditional architecture appears to have been better at ASW and ASUW 
defense. 
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• There is a strong linear correlation (R = 0.95) between rated teamwork and the 
computer generated performance score, but I do not know if this is a rater 
phenomenon or an indicator of “better” teams? (Did the observers note the 
higher performance scores and then rate the team work higher?) 

• For some tasks, the rated performance does not agree with actual performance 
as recorded by the DDD simulation. There are several instances where the 
observers consistently rated the TA teams as “better” in performing specific 
tasks yet DDD log files show there was no significant difference in TA and 
NTA performance scores for these tasks. This may indicate some amount of 
the “halo effect” influencing an observer’s rating of a team. 

Although the dimensions of task structure and the task structure diagrams based on 
the scenario for the trial runs were identical or nearly so, the resource allocation within the 
assigned organizational structures (TA and NTA) was significantly different. This 
fundamental difference in the resource allocation assigned to the TA and NTA organizational 
structures required, in my opinion, a far different mind set on the part of the players in each 
architecture for the conduct of the overall mission, and negatively affected the non traditional 
architecture players’ initial performance. This was apparent in the much steeper (larger rate 
of change in performance scores from one trial to the next) learning curve exhibited by these 
teams. It is my belief that, the human “comfort level” or familiarity with the 
situation/organization significantly influences the efficiency and effectiveness of joint 
operations. This problem is correctable and must be factored into joint training and doctrine 
for joint operations and experiments. 
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1 . 



Traditional Architecture (NPS) 



All 3 teams kept the same (3-tier) structure(s) except for attempts to tie CAS more 
tightly to the rifle companies (DM 4 and DM 5) (e.g., assign CAS to DM 1 and DM 3, or 
establish separate cells in DM 2 to coordinate with DM 4 and DM 5). 

The traditional architecture teams felt that the allocation of resources for their initial 
organization was more “realistic” than the nontraditional teams. (Perhaps what we are used to 
is considered more “realistic”.) 

2. Nontraditional Architecture (Model-Derived) 

Although all three teams selected a flat (2-tier) structure with some reallocation of 
assets, there was no consistent pattern across teams to the changes in asset allocation in the 
new architectures (perhaps because of a lack of experience, training, and doctrine to guide 
them, they were taking their “best shot” at improving their performance). Two of the teams 
allocated CAS to node DM 2 which was underutilized in the original nontraditional 
architecture. 

C. CONCLUSIONS 

An in-depth analysis of the data still needs to be completed. The initial findings that I 
presented in this chapter may not endure the full analysis by the A2C2 team. However the 
preliminary analysis of the data by the NPS research team indicates interesting results 
concerning human influence on organizational adaptation are possible. 
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VI. LESSONS LEARNED AND MODIFICATIONS AND 
IMPROVEMENTS TO THE DDD-III SIMULATION 



Upon completion of NPS experiment two, the observations of the A2C2 researchers 
and lead team members made it clear that there were ways to improve the design of 
experiment, task design process, and the data collection methods for future experiments. I 
focus here on the items of interest in my thesis, the task structure and scenario development 
and enrichment process. 

A. LESSONS LEARNED FROM THE SCENARIO DEVELOPMENT PROCESS 

Following the completion of NPS experiment one, the experiment team received 
complaints from the players about the lack of realism in the scenario. Significant efforts went 
into improving the simulation and the scenario to correct this shortcoming, but there is still 
room for continued improvement. 

1. Tradeoff Between Realism and Coordination 

There are three main areas where complaints concerning realism in the second 
experiment occurred; limited capability of the assets, rigid task performance sequencing, and 
“non-thinking” troops or the lack of “smart” forces. I will discuss these in more detail in the 
following subsections. 

a. Limited Capability Assets 

Based on the criticism concerning realism received from subjects in NPS 
experiment one, many changes were made to make NPS experiment two more realistic. 
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However, criticisms concerning the scenario’s lack of realism were still received from the 
subjects of experiment two as well, but to a lesser extent. Realism tradeoffs is a complex 
issue that I addressed during the design and development of the scenario for experiment two. 
There is a balancing act between realism and control of experiment issues. To induce DMs to 
coordinate resources to complete complex tasks with other DMs, scenario events were 
introduced in a consistent, reproducible manner. The scenario forced the coordinated use of 
multiple assets owned by multiple DMs to perform certain tasks. This resulted in some 
unrealistic restrictions since military platforms can usually conduct more than one 
operation/evolution at a time and are capable of engaging more than one target at a time. A 
scenario design that allowed the assets to more accurately reflect the real world would have 
allowed the teams to create their own task structures and avoid entirely the coordination 
events that were the focus of the experiment. Enhancements to DDD which will enable 
multiple target engagements by some of the platforms are being investigated for use in future 
experiments. 

b. Hard Prerequisites 

Designing the implementation of the scenario in the simulation so that certain 
activities must be performed before others (hard prerequisites) is helpful for ensuring that a 
team follows a desired task structure. Like the design of limited capability assets, 
development of hard prerequisites impacts the level of realism. The value of strictly 
following a desired task structure for experiment control purposes must be balanced against 
the value of allowing a team to make mistakes or solve problems on its own. This issue is 
also intertwined with DDD training, operator training, doctrine and experience level, and the 
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TA and NTA organizational architectures. Since the focus of this project is adaptation of 
organizations rather than innovative problem solving, hard prerequisites work to our 
advantage and will remain a part of the experimental design, 
c. “Smart” Forces 

In the current version of DDD, forces will continue into a hazard even after it 
has been identified unless the DM who owns the asset halts it. No message or warning is 
given to the DM, so if he isn’t focused on that area or asset, he won’t recognize the hazard 
(task), and performance points are lost. An enhancement to DDD that causes forces to stop 
when a hazard is encountered and send an alert message to the DM is being investigated. 
This may prove beneficial to the experimenters in several ways besides increasing realism. 
Fewer assets (tasks) will be “lost” due to inadvertent encounters, and the communications 
“noise” level (load level) will increase. 

2. Task Spawning 

The use of task spawning, where completion of a specific event or action triggers 
another task or event, allowed an additional degree of realism in the DDD simulation. The 
actions of the DMs are used to activate a task rather than activating tasks simply based on 
game time. For example, in the second NPS experiment, the attack on the hill triggered 
enemy air attacks. In the first NPS experiment the background tasks and obstacles appeared 
based on game time, whether the friendly forces had initiated any actions or not. 
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B. LESSONS LEARNED FROM CONDUCT OF THE EXPERIMENT 



During the conduct of the experiment and initial analysis of the data, it was apparent 
that there were several areas where the design and implementation of the experiment and data 
collection methods could be improved. 

1. Use of Confederates 

The manner in which the use of confederates in the two organizational structures was 
implemented was the source of some difficulty. First, there were only three confederates so 
they be alternated between teams and positions. While the same confederates remained paired 
with a team, they didn’t remain paired with each other or always play the same position. This 
resulted in some differences in the interactions between the DMs as a result of personality 
issues. The use of only three confederates was based on limited people in the lead team and 
scheduling constraints. The design team had felt that it would not have any significant impact 
on the results, but post-experiment analysis of the data revealed that some of the confederates 
had significantly more input during the scenario than others. If confederates are used in future 
experiments, I recommend keeping them paired with each other and filling the same DM 
positions each time to control individual DM effects throughout the experiment. If a pair of 
confederates is treated as a unit “personality”, using four confederates would allow two 
confederate pairs to be formed instead of the three confederate pairs required using only three 
confederates. 
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2. Increase Time Pressure 



Additional time pressure (workload) would have improved the experiment. Several of 
the teams in experiment two operated under a reasonable amount of time pressure. The other 
teams, composed of more operationally proficient members, appeared to work under 
relatively low time pressure while accomplishing the same tasks. The more operationally 
proficient teams tended to score well based on performance measures independent of 
workload (Noted in scores during training runs and experiment run), making it difficult to 
find any difference between the time pressure (workload) factor levels. A solution is to 
increase time pressure by increasing the workload rate. This is achieved by increasing the 
number of activities (subtasks) within the scenario or increasing the quantity and complexity 
of the coordination events. Increasing the clock time rate of the simulation is not a good 
option, when the clock time is increased, the screen display graphics do not keep pace with 
the objects’ actual positions in the data files and it becomes difficult to “tag” moving objects 
for attack or identification. 

3. Increased Number of Coordination Events 

Increasing the number of coordination events by enriching the scenario with other 
assets, tasks, and background events results in more data points for analysis. This must be 
accomplished in such a way that the overall run time of the scenario is not significantly 
increased (40 minutes). If scenario runtime becomes too long, the number of replications 
(sample size) is reduced due to the fixed, limited time the players have available for the 
experiment. 
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4. Team Formation 



The varied operational experience level of the officers performing as subjects in NPS 
experiments continues to be a challenge. Officers with significant operational experience 
more easily adapted to the scenario and tended to perform better than their classmates with 
less experience. Performance variance due to experience made it difficult to attain a 
reasonably constant level of difficulty across teams and individuals, but just the opposite is 
desired for control purposes (keep everything as constant as possible across the trials by 
design of the experiment and counterbalancing to neutralize differences between teams). This 
factor may become more pronounced as A2C2 experiments progress toward more realism 
with higher command levels and more senior players. This must be addressed as we continue 
to gather additional knowledge of adaptive command and control architectures in a joint 
operational-level context. In real world operations, this problem would hopefully be 
eliminated or mitigated by training and doctrine as well as by competent staff members to 
provide advice and recommendations. 

Officers who were operationally experienced, but played a role in the experiment 
outside of their area of expertise, did not tend to function as well as their subordinates who 
were in their area of expertise. 

While readily apparent in the small subject pool used in the A2C2 experiment two, it 
may contribute to the realism of the results. All the officers assigned to a task force will not 
have the same level of expertise and capability. The organization must determine the best use 
the assets that are allocated to it, human and equipment. 
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5. Data Collection Methods 



Data collected in the planning sessions tended to be more qualitative or subjective 
than quantitative; this made analysis of the data more challenging. Frequently the analysts 
made judgement calls based on the subjects’ statements. 

More detailed piloting and testing of the data collection forms and questionnaires is 
required. A thorough review by persons uninvolved with the original draft of these 
documents would be very helpful. Questions that I thought were straightforward and obvious 
were actually ambiguous in many cases depending on the respondent’s level in the command 
structure. 

a. Data incomplete and/or inconsistent 

The subjects and observers did not have sufficient time to complete an 
analysis and planning session and fill out the required forms. I thought the essay type 
questions used as part of the data collection forms would yield the most data, providing more 
insight into the thought processes the players used to arrive at their answers, and allowing the 
widest range of answers. Due to the limited time available for planning, reaching a consensus 
among the team members, and filling out the forms resulted in answers that were incomplete, 
hard to read, and inconsistent within a team. Post-experiment analysis required “experts” to 
fill in gaps or interpret the answers. In many cases it was necessary to go back to the video 
tapes of the planning sessions to resolve ambiguities and inconsistencies in the written 
answers. Use of multiple choice questionaires, checklists, and spreadsheets to obtain asset- 
to-DM and DM-to-task allocations may be helpful to mitigate these problems in the future. 
Other recommendations to improve the usability of the data would be to immediately follow- 
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up planning sessions with semi-structured interviews or to have the designated CJTF brief 
and defend the (re)organization to the Commander-in-Chief. Significantly more time is 
required to extract and analyze the data from oral interviews, and the interviews would 
require additional time from the subjects, either reducing the time available for DDD runs 
and planning sessions or increasing the amount of time per team to complete their trial. 

C. SUMMARY 

While it is desirable to approach the operational environment as closely as possible 
during the experiments, this must be balanced against the need for control of the experiment. 
While it may be necessary to introduced some artificialities into small scale experiments to 
ensure the phenomena that are being investigated occur, it is imperative that the artificialities 
be introduced/implemented in a way that does not alter the phenomena themselves. 

Chapter VII will be a summation of the paper and will present some short term 
research areas for future experiments. 
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VII. THESIS SUMMARY AND FUTURE RESEARCH PLANS 



The A2C2 project is an ongoing research effort, building on the data collected and the 
lessons learned in each experimental cycle. The preliminary findings of the data from NPS 
experiment two have piqued the interest of ONR and the research teams in several additional 
areas. I summarize my thesis, then list some of the short term future research areas for follow 
on experiments. 

A. SUMMARY OF THESIS 

This thesis was conducted as a part of the Adaptive Architectures for Command and 
Control (A2C2) research project, which seeks to explore how teams adapt in reaction to 
changes in resource availability and mission caused by internal and external triggers. The 
project’s second NPS experiment involved studying interaction between resources and task 
structures and organizational structure and the resulting adaptation of organizational 
structure. 

This thesis describes a process for developing military operational scenarios within a 
task structure context. First, I conducted a review of Michael Berigan’s work [Berigan, 1996] 
which defines the dimensions of task structure applicable to this project, develops a grading 
scale for each dimension, gives examples of the dimensions and grades each example, and 
describes how changes in one dimension might affect other dimensions. Then a method for 
developing scenarios in accordance with a predetermined structure and visualizing tasks is 
described, including a task structure diagram and a description of a task design process using 
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the diagram and the dimensions previously delineated. I then apply the task design process by 
developing scenarios and organization structures for the experiment that allow an evaluation 
of the interactions between task/mission and organizational structure across one dimension of 
task structure, coordination requirements. Finally, a description of the experiment is given, 
including discussion of the scenarios and organizational structures, preliminary findings, and 
lessons learned from the experiment with regard to scenario design. 

B. FUTURE RESEARCH AREAS 

Research efforts will continue to focus on the concept of adaptation . The first phase 
of the A2C2 project developed joint C2 scenarios, investigated the mapping of tasks onto 
architectures, and studied structural and architectural variables and their effects on 
organizational performance and began looking at adaptation. The next step in the A2C2 
research effort will focus on the investigation, both theoretically and experimentally, of the 
variable of adaptation. The next phase of A2C2 research will focus on: 

• Identifying and understanding the decision of organizations to adapt their 
organizational structure. 

• Understanding the consequences of adaptation in terms of organizational 
processes and performance. 

An area of high interest is the concept of incremental organizational changes as 
opposed to sudden drastic switches in structure. Several sources in the organizational theory 
literature argue that organizations resist radical changes to their structure even when changes 
in the environment warrant a drastic change. This is particularly true after having performed 
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well under a given architecture. In other words, human organizations may prefer familiarity 
or robustness of performance across a wide range of tasks and resources to optimality of an 
organizational structure to one specific mission. 

For a more detailed look at proposed research, see Adaptive Architectures for 
Command and Control (A2C2) Research Plans (Version 1.1), June 1997, by Daniel Serfaty 
of Aptima, Inc. 
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APPENDIX A. OPORDER’s, ORDMOD’s, AND QUICK REFERENCE 

SHEETS 



Appendix A contains the OPORDER’s for the TA and NTA organizations, the 
ORDMOD’s for the noncombatant evacuation operation (NEO) vignettes (one adding tasks to 
the mission, the other taking assets away from the organization), and the quick reference sheets 
which were provided to the players. 

Traditional Architecture OPORDER 106 

Nontraditional Architecture OPORDER 113 

ORDMOD (add NEO) 120 

ORDMOD (remove assets) 123 

Quick Reference Sheets 126 

DDD Tutorials 128 
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FOR OFFICIAL USE ONLY (FOR TRAINING PURPOSES ONLY) 



IMMEDIATE 



TA 



FROM: USCINCMED NAPLES IT 

CJTF FOUR 

TO: CJCS WASHINGTON DC 

USCINCCENT MACDILL AFB FL 
USCINCLANT NORFOLK VA 
USCINCEUR VAJHINGEN GE 
CINCFOR FT MCPHERSON GA 
USCINCPAC HONOLULU HI 
USCINCTRANS SCOTT AFB IL 
USCINCSTRAT OFFUTT AFB NE 
COMMARFORPAC HONOLULU HI 
CINCPACFLT HONOLULU HI 
JTF FOUR 

INFO: WHITEHOUSE SITUATION ROOM WASHINGTON DC 

SECSTATE WASHINGTON DC 
SECDEF WASHINGTON DC 
CSA WASHINGTON DC 
CMC WASHINGTON DC 
CNO WASHINGTON DC 

DISTR: CINC/DCINC/CCJ 1 /CC J 2/CCJ 3/CC J4/CC J5/CC J 6 

FOR OFFICIAL USE ONLY 
OPER/THUNDER SPEAR// 

MSGED/ORDER/USCINCCENT// 

AMPN/SPECIAL HANDLING INSTRUCTIONS 
REF/A/ORDER/CJCS/Ol 1742Z NOV 96// 

REF/B/ORDER/CJCS/041 142Z NOV 96// 

NARR/JT STRAT CAP PLN (FY 96), CJCS ALERT ORDER// 
ORDTYP/OPORD/USCINCCENT 11-96// 

MAP/1015/TUNSIA// 

MAP/ 1020/Yang// 

NARR/SCALE 1:100,000// 

TIMEZONE/Z// 

HEADING/TASK ORGANIZATION// 
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UNITS 



/UNITDES 



/UNITLOC 



/CMNTS 



/USCINCLANT 

/USCINCEUR 

/CENCFOR 



/NORFOLK VA 
/VAIHINGEN GE 



/FT MCPHERSON GA 



/USCINCPAC 

/USCINCTRANS 



/HONOLULU HI 
/SCOTT AFB IL 



/2 TAC ARLFT SQ 



/USCENCSTRAT 

/COMMARFORPAC 

/CINCPACFLT 

/HQ USMEDCOM FWD 



/OFFUTT AFB NE 
/HONOLULU HI 



16 KC-10 
12 RC-135 
/I MEB 



/HONOLULU HI 



/(JTF 4) 



/HQ USMEDAF (MINUS) 

/HQ USNAVMED (MINUS) 

/SUPPORTING FORCES 
/COMSUPNAVFOR 
/ MPS// 

GENTEXT/SITUATION 

1. (FOUO) Yang has attacked the friendly nation of Ying. Attacking forces have succeeded in seizing 
Yingian port of Plethora. Yingian government has requested U.S. assistance in taking back port of 
Plethora and driving Yangian forces from Ying. 

A. (FOUO) ENEMY FORCES 

1 . (FOUO) See current SITREP and DIN. Port of Plethora protected by 
obstructions, mines, obstacles, and the presence of hidden enemy among the port facility buildings. Two 
beaches approx. 5 miles south of the port may be suitable for amphibious assault. Northernmost 
beach (designated “Red Beach”) has road leading to the port. Southernmost beach (designated “Blue 
Beach”) has a road leading to the airfield. Waterborne approaches to the beaches are possibly mined. 
Commanding terrain to north of Red Beach believed occupied by enemy Heavy Mortar Platoon with 
a platoon of Infantry for security. This terrain dominates both Red Beach and the port. Seizure and 
retention of this dominant terrain should be considered essential for successful attack on Red Beach 
and port. 

(2) (FOUO) Believed to be at port, but hidden from view, is company-sized armored 
counterattack force that could move toward Red Beach in response to any amphibious assault. 

Similar counterattack force may exist at airfield, which is located about 5 miles inland from the Blue 
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Beach. These counterattack forces could inflict serious damage if not interdicted before they reach 
either beach. Off-road terrain between beach, port, airfield, and commanding terrain is swampy and 
treacherous; and is unsuitable for travel. Thus, all travel must be on the two roads. It is believed that 
one or both of the roads will be mined. Locations of any minefields are currently unknown. Port, 
airfield, both roads, both beaches, and commanding terrain are located within range of artillery 
strong-points. Northernmost strong-point can range Red Beach and port. Southernmost strong-point 
can range both Blue Beach and airfield. Artillery pieces are housed in reinforced concrete bunkers, 
with ammunition stored in deep underground bunkers. It is unlikely that even concentrated air 
attacks will completely disable the artillery strong-points. Enemy can be expected to wheel out 
artillery pieces (from 8 to 24 at a time), set up, sight in, and fire within 5 minutes. If friendly forces 
can get effective NSFS on target in less than 5 minutes, the enemy will most probably wheel their 
artillery pieces back into bunkers and wait until another time. 

(3) (FOUO) Enemy also has several Frog Missile Launchers known to be capable of carrying 
chemical munitions. Frogs believed to be hidden in the vicinity of both artillery strong-points. They 
can emerge from covered positions, prepare warheads, and fire missiles within 10 minutes. Past 
experience has shown that Frog crews are more stalwart than artillery crews. They will continue to 
prepare and launch their missiles even if they are being suppressed by NSFS or artillery. 

(4) (FOUO) Submarine threat is considerable. Enemy has at least one Alfa-Class submarine 
known to be in the area, and possibly more. 

(5) (FOUO) Enemy possess HIND Helicopters, which have demonstrated the capability to 
launch anti-ship missiles. The DDG, CG and CV possess capabilities to counter these helicopters. 

2. FOUO) The enemy has significant air strike capability, and can launch 
anti-ship missiles from most of its strike aircraft. 

(7) (FOUO) The enemy’s Special Forces also possess numerous fast patrol boats, that can either 
fire very potent Russian torpedoes or be loaded with explosives for suicide missions. 

(8) (FOUO) There are Silkworm threats throughout the area. The Silkworm missiles are placed 
in residential neighborhoods because they know U.S. will be reluctant to target residential areas. 
Accordingly, if U.S. warships want to target a Silkworm launcher, they must first get visual 
confirmation of its presence, using theater RECON (TARPS) assets, and any strike must use 
precision guided munitions. 

B. (FOUO) FRIENDLY FORCES. JTF 4 will be comprised primarily of assets organic to 
Mediterranean Command (MEDCOM). A theater-level JFACC and other friendly forces are 
operating against the enemy in Ying, but not in concert with the JTF. 
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3. (FOUO) JTF 4 will consist of one RECON (TARPS), and subordinate units 
(4.1, 4.2, 4.3, 4.1.1, 4.3.1). 

4. (FOUO) JTG 4.1 will consist of one DDG, one LPD, two Cobra Sections, 
one Huey MEDEVAC, and one MH-53 MCM. 

(3) (FOUO) JTG 4.2 will consist of one CV, one CG, two FFG’s, eight Fighter Sections, and 
eight CAS Sections. 

5. (FOUO) JTG 4.3 will consist of one DDG, one LHA, two Cobra Sections, 
one Huey MEDEVAC, and one MH-53 MCM. 

(5) (FOUO) JTU 4.1.1 will consist of three Rifle Companies, one Engineer Platoon, one Stinger 
Detachment, two AAAV Platoons, and one MV22. 

(6) (FOUO) JTU 4.3.1 will consist of three Rifle Companies, one Engineer Platoon, one Stinger 
Detachment, one AAAV Platoon, and two MV22s. 

(7) (FOUO) Continuous coverage by RECON (TARPS) will be maintained in general support 
of theater CINC. May be tasked with any immediate imagery requirements.// 

GENTEXT/MISSION/ 

2. (FOUO) On order, JTF 4 ground forces will seize and defend Yingian Port of Plethora, to allow 

introduction of follow on forces in support of Yingian government troops. Sea-based forces will 
support amphibious assault with CAS, naval gunfire, and air defense assets.// 

GENTEXT/EXECUTION/ 

3. (FOUO) CONCEPT OF OPERATIONS 

A. GROUND. Each GCE will simultaneously land one AAAV-Mounted Platoon on respective 
beach. JTU 4.3.1 will simultaneously take commanding terrain with one MV22. Once BOTH 
beaches and commanding terrain are secure, the two AAAV-Mounted Platoons will proceed down 
the roads from their respective beaches, clearing minefields with Engineer Platoons, killing 
counterattack forces with Cobra Sections, and conducting MEDEVACS as necessary. Once the 
roads have been cleared, the AAAV-Mounted Platoons will take the port and airfield. JTU 4.1.1s 
AAAV-Mounted Platoon will be assisted in its attack of the airfield by a MV22. It is important that 
once the AAAV-Mounted Platoons land on the beach, the airfield and port be taken as quickly as 
possible, before the enemy has a chance to organize his defense and send reinforcements. We would 
like to conduct the final assaults on the airfield and port simultaneously, in order to present the 
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enemy commander with the most confusing, dilemma-filled environment possible. However, if one 
attack must occur before the other, the airfield has the priority. 

B. MARITIME. Due to hydrographic limitations, the DDG’s and the CV will have to be 
significantly separated during the operation, enough to preclude them from being under a Joint Air 
Defense umbrella provided by the CG. Thus, the CG will remain with the CV, but will position itself 
so that it can rapidly move from the CV to the DDG’s if that becomes necessary. Additionally, the 
two DDG’s are inshore, providing NSFS support, while the FFG’s are the primary ASW platform for 
the CV. The FFG’s performing ASW will, like the CG, position themselves so that they can quickly 
move to support the DDG’s if that is necessary. 

4. (FOUO) TASK ASSIGNMENT JTU 4.3.1. On order from JTF 4, land one AAAV-Mounted Platoon 

on Red Beach. Simultaneously seize commanding terrain to the north of Red Beach with one MV22. 
Once the beach and commanding terrain are secure, attack along the road from the beach to the port, 
clearing minefields with Engineer Platoon, killing counterattack forces with Cobras and conducting 
MEDEVACS as necessary. Once the roads have been cleared, attack the port with the AAAV- 
Mounted Platoon. 

5. (FOUO) TASK ASSIGNMENT JTU 4.1.1. On order from JTF 4, land one AAAV-Mounted Platoon 

on Blue Beach. Once the beach is secure, attack along the road from beach to airfield with AAAV- 
Mounted Platoon, clearing minefields with Engineer Platoon, killing counterattack forces with 
Cobras, and conducting MEDEVACS as necessary. 

6. (FOUO) TASK ASSIGNMENT JTG 4.2. Keep two elements of CAS on standby at all times: one to 

be used against Frog or Scuds, and the other to be used against Silkworms. CV will provide 3 
sections of air defense aircraft, with one CAP station over the CV and the others over the DDG’s. 
FFG’s will provide ASW. 

7. (FOUO) TASK ASSIGNMENT JTG 4.1 and JTG 4.3. On order from JTF 4, units will clear mines 

from the beaches. Units will launch Marines for assault on Red and Blue Beaches. DDG’s will 
suppress artillery strong-points ashore when requested to do so. Units will provide all MEDEVAC 
support and all Cobra support. 

8. (FOUO) COORDINATING INSTRUCTIONS. 

A. . (FOUO) This order effective for planning upon receipt and execution on order. 

B. (FOUO) Dirlauth for planning and operations with Info CJCS and CINCMED. 

C. (FOUO) ROE will be per CINCMED OPLAN 1234. 
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D. (FOUO) If the airfield attack is held up for any reason, the port attack will be 

delayed to retain the synergism of concurrent attacks. If the port attack is held up, the airfield attack will 
go forward. 

E. (FOUO) JTU 4.1.1’s attack on the airfield has priority, because buildup of forces 
can be most quickly and effectively achieved through air transport. 

F. (FOUO) Enemy patrol boats or other surface craft will be engaged by the DDG’s. 

G. (FOUO) If both the DDG and the CV are threatened by the enemy, the DDG has 
priority of support against submarine threats, fixed-wing air threats, and patrol boats. 

H. (FOUO) If there is a threat of an air attack against the DDG, the DDG will be protected by the CG or 
a CAP. 

I. (FOUO) The FFG performing ASW and the CG will remain with the CV unless 

required by the DDG to meet a specific threat. In absence of such a specific threat, CV is considered a 
more likely target for the enemy. 

J. (FOUO) CV has priority against land based Silkworm sites and helicopters. 

K. (FOUO) The fighters will man at least 2 CAP stations. 

L. (FOUO) DDG’s will be in position to provide NSFS support against artillery 
strong-points, and will man fire support stations (FSS) about 4 miles directly east of the port. 



GENTEXT/ADMIN AND LOG/ 

9. (FOUO) Per CINCMED OPLAN 1234, as amended herein.// 

GENTEXT/COMMAND AND SIGNAL/ 

10. (FOUO) USCINCMED is supported CINC. 

1 1 . (FOUO) CJTF 4 is on-the-scene Commander and will exercise OPCON of advance forces until HQ 
USCINCMED FWD is activated. 

12. (FOUO) Command relationships as outlined in Annex J, CINCMED OPLAN 1234. 
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13. (FOUO) Communications guidance as outlines in Annex K, CINCMED OPLAN 1234 as amended 
herein.// 

AKNLDG/Y// 

DECL/OADR// 
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IMMEDIATE 



NTA 



FROM: USCINCMED NAPLES IT 

CJTF FOUR 

TO: CJCS WASHINGTON DC 

USCINCCENT MACDELL AFB FL 
USCINCLANT NORFOLK VA 
USCINCEUR VAIHINGEN GE 
CENCFOR FT MCPHERSON GA 
USCINCPAC HONOLULU HI 
USCINCTRANS SCOTT AFB IL 
USCINCSTRAT OFFUTT AFB NE 
COMMARFORPAC HONOLULU HI 
CINCPACFLT HONOLULU HI 
JTF FOUR 

INFO: WHITEHOUSE SITUATION ROOM WASHINGTON DC 

SECSTATE WASHINGTON DC 
SECDEF WASHINGTON DC 
CSA WASHINGTON DC 
CMC WASHINGTON DC 
CNO WASHINGTON DC 

DISTR: CINC/DCINC/CCJ 1/CC J 2/CCJ 3/CCJ 4/CCJ 5/CCJ 6 

FOR OFFICIAL USE ONLY 
OPER/THUNDER SPEAR// 

MSGID/ORDER/USCINCCENT// 

AMPN/SPEC IAL HANDLING INSTRUCTIONS 
REF/A/ORDER/CJCS/Ol 1742Z NOV 96// 

REF/B/ORDER/CJCS/041 142Z NOV 96// 

NARR/JT STRAT CAP PLN (FY 96), CJCS ALERT ORDER// 
ORDTYP/OPORD/USCINCCENT 1 1-96// 

MAP/10 15/TUNSIA// 

MAP/1 020/YANG// 

NARR/SCALE 1:100,000// 

TIMEZONE/Z// 

HEADING/TASK ORGANIZATION// 
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UNITS 



/UNITDES 



/UNITLOC 



/CMNTS 



/USCENCLANT 

/USCENCEUR 

/CINCFOR 



/NORFOLK VA 

/VAIHINGEN GE 
/FT MCPHERSON GA 
/HONOLULU HI 
/SCOTT AFB IL 



/USCINCPAC 

/USCINCTRANS 



/2TAC ARLFTSQ 
/6 KC-10 
/2 RC-135 



/USCINCSTRAT 

/COMMARFORPAC 

/CINCPACFLT 

/HQ USMEDCOM FWD 



/OFFUTTAFB NE 



/HONOLULU HI 
/HONOLULU HI 



/(JTF 4) 



/I MEB 



/HQ USMEDAF (MINUS) 

/HQ USNAVMED (MINUS) 

/SUPPORTING FORCES 

/COMSUPNAVFOR 

/MPS// 

GENTEXT/SITUATION 

1. (FOUO) Yang has attacked the friendly nation of Ying. Attacking forces have succeeded in 
seizing Yingian port of Plethora. Yingian government has requested U.S. assistance in taking back 
port of Plethora and driving Yangian forces from Ying. 

A. (FOUO) ENEMY FORCES 

6. (FOUO) See current SITREP and DIN. Port of Plethora protected by 

obstructions, mines, obstacles, and the presence of hidden enemy among the port facility buildings. 
Two beaches approx. 5 miles south of the port may be suitable for amphibious assault. Northernmost 
beach (designated “Red Beach”) has road leading to the port. Southernmost beach (designated “Blue 
Beach”) has a road leading to the airfield. Waterborne approaches to the beaches are possibly mined. 
Commanding terrain to north of Red Beach believed occupied by enemy Heavy Mortar Platoon with 
a platoon of Infantry for security. This terrain dominates both Red Beach and the port. Seizure and 
retention of this dominant terrain should be considered essential for successful attack on Red Beach 



and port. 
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(2) (FOUO) Believed to be at port, but hidden from view, is company-sized armored 
counterattack force that could move toward Red Beach in response to any amphibious assault. 

Similar counterattack force may exist at airfield, which is located about 5 miles inland from the Blue 
Beach. These counterattack forces could inflict serious damage if not interdicted before they reach 
either beach. Off-road terrain between beach, port, airfield, and commanding terrain is swampy and 
treacherous; and is unsuitable for travel. Thus, all travel must be on the two roads. It is believed that 
one or both of the roads will be mined. Locations of any minefields are currently unknown. Port, 
airfield, both roads, both beaches, and commanding terrain are located within range of artillery 
strong-points. Northernmost strong-point can range Red Beach and port. Southernmost strong-point 
can range both Blue Beach and airfield. Artillery pieces are housed in reinforced concrete bunkers, 
with ammunition stored in deep underground bunkers. It is unlikely that even concentrated air 
attacks will completely disable the artillery strong-points. Enemy can be expected to wheel out 
artillery pieces (from 8 to 24 at a time), set up, sight in, and fire within 5 minutes. If friendly forces 
can get effective NSFS on target in less than 5 minutes, the enemy will most probably wheel their 
artillery pieces back into bunkers and wait until another time. 

(3) (FOUO) Enemy also has several Frog Missile Launchers known to be capable of carrying 
chemical munitions. Frogs believed to be hidden in the vicinity of both artillery strong-points. They 
can emerge from covered positions, prepare warheads, and fire missiles within 10 minutes. Past 
experience has shown that Frog crews are more stalwart than artillery crews. They will continue to 
prepare and launch their missiles even if they are being suppressed by NSFS or artillery. 

(4) (FOUO) Submarine threat is considerable. Enemy has at least one Alfa-Class submarine 
known to be in the area, and possibly more. 

(5) (FOUO) Enemy possess HIND Helicopters, which have demonstrated the capability to 
launch anti-ship missiles. The DDG, CG and CV possess capabilities to counter these helicopters. 

7. (FOUO) The enemy has significant air strike capability, and can launch 
anti-ship missiles from most of its strike aircraft. 

(7) (FOUO) The enemy’s Special Forces also possess numerous fast patrol boats, that can either 
fire very potent Russian torpedoes or be loaded with explosives for suicide missions. 

(8) (FOUO) There are Silkworm threats throughout the area. The Silkworm missiles are placed 
in residential neighborhoods because they know U.S. will be reluctant to target residential areas. 
Accordingly, if U.S. warships want to target a Silkworm launcher, they must first get visual 
confirmation of its presence, using theater RECON (TARPS) assets, and any strike must use 
precision guided munitions. 
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B. (FOUO) FRIENDLY FORCES. JTF 4 will be comprised primarily of assets organic to 
Mediterranean Command (MEDCOM). A theater-level JFACC and other friendly forces are 
operating against the enemy in Ying, but not in concert with the JTF. 

(1) (FOUO) JTF 4 will consist of one CV, one RECON (T ARPS), eight CAS 

Sections and subordinate units (4.1, 4.2, 4.3, 4.2.1, 4.2.2). 

8. (FOUO) JTU 4.1 will consist of three Rifle Companies, one LHA, one 

AAAV Platoon, two MV22s, and one Stinger Detachment. 

(3) (FOUO) JTU 4.2 will consist of two Cobra Sections. 

9. (FOUO) JTU 4.3 will consist of three Rifle Companies, one LPD, two 

AAAV Platoons, one MV22, one Stinger Detachment, and two Cobra Sections. 

(5) (FOUO) JTG 4.2. 1 will consist of two DDGs, one CG, one Engineer Platoon, one Huey 
MEDEVAC, and one MH-53 MCM. 

(6) (FOUO) JTG 4.2.2 will consist of two FFGs, one Engineer Platoon, one Huey MEDEVAC, 
one MH-53 MCM, and eight Fighter Sections. 

(7) (FOUO) Continuous coverage by RECON (TARPS) will be maintained in general support 
of theater CINC. May be tasked with any immediate imagery requirements.// 

GENTEXT/MISSION/ 

2. (FOUO) On order, JTF 4 ground forces will seize and defend Yingian Port of Plethora, to allow 
introduction of follow on forces in support of Yingian government troops. Sea-based forces will 
support amphibious assault with CAS, naval gunfire, and air defense assets.// 

GENTEXT/EXECUTION/ 

10. (FOUO) CONCEPT OF OPERATIONS 

A. GROUND. Each GCE will simultaneously land one AAAV-Mounted Platoon on respective 
beach. JTU 4.1 will simultaneously take commanding terrain with one MV22. Once BOTH beaches 
and commanding terrain are secure, the two AAAV-Mounted Platoons will proceed down the roads 
from their respective beaches, clearing minefields with Engineer Platoons, killing counterattack 
forces with Cobra Sections, and conducting MEDEVACS as necessary. Once the roads have been 
cleared, the AAAV-Mounted Platoons will take the port and airfield. It is important that once the 
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AAAV-Mounted Platoons land on the beach, the airfield and port be taken as quickly as possible, 
before the enemy has a chance to organize his defense and send reinforcements. We would like to 
conduct the final assaults on the airfield and port simultaneously, in order to present the enemy 
commander with the most confusing, dilemma-filled environment possible. However, if one attack 
must occur before the other, the airfield has the priority. 

B. MARITIME. Due to hydrographic limitations, the DDG and the CV will have to be significantly 
separated during the operation, enough to preclude them from being under a Joint Air Defense 
umbrella provided by the CG. Thus, the CG will remain with the CV, but will position itself so that 
it can rapidly move from the CV to the DDG if that becomes necessary. Additionally, the two 
DDG’s are inshore, providing NSFS support, while the FFG is the primary ASW platform for the 
CV. The FFG performing ASW will, like the CG, position itself so that it can quickly move to 
support the DDG if that is necessary. 

4. (FOUO) TASK ASSIGNMENT JTU 4.1. On order from JTF 4, land one AAAV-Mounted Platoon 

on Red Beach. Simultaneously seize commanding terrain to the north of Red Beach with one MV22. 
Once the beach and commanding terrain are secure, attack along the road from the beach to the port, 
clearing minefields with Engineer Platoon, killing counterattack forces with Cobras and conducting 
MEDEVACS as necessary. Once the roads have been cleared, attack the port with the AAAV- 
Mounted Platoon. 

5. (FOUO) TASK ASSIGNMENT JTU 4.3. On order from JTF 4, land one AAAV-Mounted Platoon on 

Blue Beach. Once the beach is secure, attack along the road from beach to airfield with AAAV- 
Mounted Platoon, clearing minefields with Engineer Platoon, killing counterattack forces with 
Cobras, and conducting MEDEVACS as necessary. Once the roads have been cleared, conduct a 
coordinated attack on the airfield with MV22. 

6. (FOUO) TASK ASSIGNMENT JTU 4. Keep two elements of CAS on standby at all times: one to be 

used against Frog or Scuds, and the other to be used against Silkworms. CV will provide 3 sections 
of air defense aircraft, with one CAP station over the CV and the others over the DDGs. 

7. (FOUO) TASK ASSIGNMENT JTG 4.2, JTG 4.2.1 and JTG 4.2.2. On order from JTF 4, JTG 4.2 

will coordinate JTG 4.2.1 and JTG 4.2.2 to clear mines from Red and Blue Beaches, and launch 
Marines for assault on Red and Blue Beaches. Additionally, JTG 4.2 will coordinate JTG 4.2.1 and 
JTG 4.2.2 to defend northern and southern sectors, provide NSFS for artillery strong-points, provide 
MEDEVAC support, provide Engineer support, provide ASW with the FFGs and provide fighter 
support. JTG 4.2 will provide Cobra support. 

8. (FOUO) COORDINATING INSTRUCTIONS. 
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A. (FOUO) This order effective for planning upon receipt and execution on order. 

B. (FOUO) Dirlauth for planning and operations with Info CJCS and CINCMED. 

C. (FOUO) ROE will be per CINCMED OPLAN 1234. 

D. (FOUO) If the airfield attack is held up for any reason, the port attack will be 

delayed to retain the synergism of concurrent attacks. If the port attack is held up, the airfield attack will 
go forward. 

E. . (FOUO) Unit 4.3’s attack on the airfield has priority, because buildup of forces 
can be most quickly and effectively achieved through air transport. 

F. (FOUO) Enemy patrol boats or other surface craft will be engaged by the DDGs. 

G. (FOUO) If both the DDG and the CV are threatened by the enemy, the DDG has 
priority of support against submarine threats, fixed-wing air threats, and patrol boats. 

H. (FOUO) If there is a threat of an air attack against the DDG, the DDG will be protected by the 
CG or a CAP. 

I. (FOUO) The FFG performing ASW and the CG will remain with the CV unless 

required by the DDG to meet a specific threat. In absence of such a specific threat, CV is considered a 
more likely target for the enemy. 

J. (FOUO) CV has priority against land based Silkworm sites and helicopters. 

K. (FOUO) The fighters will man at least 2 CAP stations. 

L. (FOUO) DDG’s will be in position to provide NSFS support against artillery strong-points, and 
will man fire support stations (FSS) about 4 miles directly east of the port. // 

M. (FOUO) Stringers are the only Close Air Support weapon available to JTF 4.1.1 and 
JTF 4.3.1.// 

GENTEXT/ADMIN AND LOG/ 

9. (FOUO) Per CINCMED OPLAN 1234, as amended herein.// 

GENTEXT/COMMAND AND SIGNAL/ 
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10. (FOUO) USCINCMED is supported CINC. 

11. (FOUO) CJTF 4 is on-the-scene Commander and will exercise OPCON of advance forces until HQ 
USCINCMED FWD is activated. 

12. (FOUO) Command relationships as outlined in Annex J, CINCMED OPLAN 1234. 

13. (FOUO) Communications guidance as outlines in Annex K, CINCMED OPLAN 1234 as amended 
herein.// 

AKNLDG/Y// 

DECL/OADR// 
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IMMEDIATE 



F2 



FROM: USCINCMED NAPLES IT 

CJTF FOUR 

TO: CJCS WASHINGTON DC 

USCINCCENT MACDILL AFB FL 
USCENCLANT NORFOLK VA 
USCINCEUR VAIHINGEN GE 
CENCFOR FT MCPHERSON GA 
USCENCPAC HONOLULU HI 
USCINCTRANS SCOTT AFB IL 
USCINCSTRAT OFFUTT AFB NE 
COMMARFORPAC HONOLULU HI 
CENCPACFLT HONOLULU HI 
JTF FOUR 

INFO: WHITEHOUSE SITUATION ROOM WASHINGTON DC 

SECSTATE WASHINGTON DC 
SECDEF WASHINGTON DC 
CSA WASHINGTON DC 
CMC WASHINGTON DC 
CNO WASHINGTON DC 

DISTR: CINC/DCINC/CCJ 1 /CC J 2/CC J 3/CC J.4/CC J 5/CC J 6 

FOR OFFICIAL USE ONLY 
OPER/THUNDER SPEAR// 

MSGID/ORDER/USCINCCENT// 

AMPN/SPECIAL HANDLING INSTRUCTIONS 
REF/A/ORDER/CJCS/Ol 1742Z NOV 96// 

REF/B/ORDER/CJCS/041 142Z NOV 96// 

NARR/JT STRAT CAP PLN (FY 96), CJCS ALERT ORDER// 
ORDTYP/OPORD/USCINCCENT 1 1-96// 

MAP/1015/TUNSIA// 

MAP/ 1 020/Y AN G// 

NARR/SCALE 1:100,000// 

TIMEZONE/Z// 

/ARG 55.2 
/ 1 MEB 
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/MPS// 

GENTEXT/S ITU ATION 

1. (FOUO) Yang has attacked the friendly nation of Ying. Attacking forces have succeeded in seizing 
Yingian port of Plethora. Yingian government has requested U.S. assistance in taking back port of 
Plethora and driving Yangian forces from Ying. 

A. (FOUO) ENEMY FORCES See OPORDER Thunder Spear. 

B. (FOUO) FRIENDLY FORCES. See OPORDER Thunder Spear. 

GENTEXT/MISSION/ 

2. (FOUO) On order, JTF 4 will conduct a NEO at Plethora.// 

GENTEXT/EXECUTION/ 

3. (FOUO) CONCEPT OF OPERATIONS. 

A. (FOUO) Conduct Noncombatant Evacuation Order to remove United States citizens located in 
and around the port of Plethora. LA.W Operation Thunder Spear. Special Forces personnel will be 
provided for the execution of the NEO Operation. Current chain of command may be altered to carry 
out this mission.// 

4. (FOUO) COORDINATING INSTRUCTIONS. 

A. (FOUO) This order effective for planning upon receipt and execution on order. 
GENTEXT/ADMIN AND LOG/ 

5. (FOUO) Per OPORDER Thunder Spear.// 

GENTEXT/COMMAND AND SIGNAL/ 

6. (FOUO) USCINCMED is supported CINC.// 

7. (FOUO) CJTF 4 is on-the-scene Commander and will exercise OPCON of advance forces until HQ 

USCINCMED FWD is activated. 

8. (FOUO) Command relationships as outlined in Annex J, CINCMED OPLAN 1234. 
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9. (FOUO) Communications guidance as outlines in Annex K, CINCMED OPLAN 1234 as amended 
herein.// 

AKNLDG/Y // 

DECL/OADR// 
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IMMEDIATE 



F3 



FROM: USCINCMED NAPLES IT 

CJTF FOUR 

TO: CJCS WASHINGTON DC 

USCINCCENT MACD1LL AFB FL 
USCINCLANT NORFOLK VA 
USCINCEUR VAIHINGEN GE 
CINCFOR FT MCPHERSON GA 
USCINCPAC HONOLULU HI 
USCINCTRANS SCOTT AFB IL 
USCENCSTRAT OFFUTT AFB NE 
COMMARFORPAC HONOLULU HI 
CINCPACFLT HONOLULU HI 
JTF FOUR 

INFO: WHITEHOUSE SITUATION ROOM WASHINGTON DC 

SECSTATE WASHINGTON DC 
SECDEF WASHINGTON DC 
CSA WASHINGTON DC 
CMC WASHINGTON DC 
CNO WASHINGTON DC 

DISTR: CENC/DCINC/CCJ 1 /CC J 2/CC J 3/CC J 4/CCJ 5/CCJ 6 

FOR OFFICIAL USE ONLY 
OPER/THUNDER SPEAR// 

MSGED/ORDER/USCINCCENT// 

AMPN/SPECIAL HANDLING INSTRUCTIONS 
REF/A/ORDER/CJCS/OI 1742Z NOV 96// 

REF/B/ORDER/CJ CS/04 1 142Z NOV 96// 

NARR/JT STRAT CAP PLN (FY 96), CJCS ALERT ORDER// 
ORDTYP/OPORD/USCENCCENT 11-96// 

MAP/1 01 5/TUNS IA// 

MAP/ 1020/YANG// 

NARR/SCALE 1:100,000// 

TIMEZONE/Z// 

/ 1 MEB 
/MPS// 
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GENTEXT/SITUATION 

1. (FOUO) Yang has attacked the friendly nation of Ying. Attacking forces have succeeded in seizing 
Yingian port of Plethora. Yingian government has requested U.S. assistance in taking back port of 
Plethora and driving Yangian forces from Ying. 

A. (FOUO) ENEMY FORCES See OPORDER Thunder Spear. 

B. (FOUO) FRIENDLY FORCES. See OPORDER Thunder Spear. 

GENTEXT/MISSION/ 

2. (FOUO) JTF 4 can reorganize the current chain of command and unit assets prior to execution of 

Operation Thunder Spear.// 

GENTEXT/EXECUTION/ 

3. (FOUO) CONCEPT OF OPERATIONS. 

A. (FOUO) JTF personnel will evaluate current command structure and unit assets. 

Changes can be made to the chain of command and/or the unit assets to create a “better” structure for the 

execution of Operation Thunder Spear.// 

1. (FOUO) TASK ASSIGNMENT JTF 4. JTF 4 will provide the following assets to JTF 195 

1 LPD 1 LHA 2 Rifle Co 2 Cobra Sections 

1 Eng. Pit 1 MEDEVAC 1 MCM 1 Stinger Detachment 

2 CAS 2 Fighters 1 DDG 1 FFG 

1 AAAV 1 MV22 

5. (FOUO) COORDINATING INSTRUCTIONS. 

A. (FOUO) This order effective for planning upon receipt and execution on order. 

B. (FOUO) There are NO restrictions on how the units can be reconstructed. 
GENTEXT/ADMIN AND LOG/ 

6. (FOUO) Per OPORDER Thunder Spear.// 
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GENTEXT/COMMAND AND SIGNAL/ 

7. (FOUO) USCINCMED is supported CINC.// 

8. (FOUO) CJTF 4 is on-the-scene Commander and will exercise OPCON of advance forces until HQ 

USCINCMED FWD is activated. 

9. (FOUO) Command relationships as outlined in Annex J, CENCMED OPLAN 1234. 

10. (FOUO) Communications guidance as outlines in Annex K, CINCMED OPLAN 1234 as amended 
herein.// 

AKNLDG/Y// 

DECL/OADR// 
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TASK 

NAME 


POSSIBLE 

RESOURCE 

COMBO 


POSSIBLE 

RESOURCE 

COMBO 


POSSIBLE 

RESOURCE 

COMBO 


POSSIBLE 

RESOURCE 

COMBO 


HILL 


1 RIFLE CO 
1 CAS 


1 RIFLE CO 

2 DDG 


1 RIFLE CO 

1DDG 

1FFG 


1 RIFLE CO 
1 CG 
1 FFG 


RED BEACH 


1 CAS 


2 DDG 


I DDG 
1FFG 


1 COBRA SEC 


BLUE 

BEACH 


1 RIFLE CO 
1 CAS 


1 RIFLE CO 

2 DDG 


1 RIFLE CO 

1DDG 

1FFG 


1 RIFLE CO 
1 COBRA SEC 


ARTILLERY 


1DDG 


1 CAS 


2 FFG 




FROG 

LAUNCH 


1DDG 


1 CAS 


2 FFG 




SILKWORM 


1 CAS 








MINE LAND 


1 ENG PLT 








MINE SEA 


1 MCM 
HELO 








STRIKE AIR 


1 FIGHTER 
SEC 


1 STNGR 
DETCH 


1DDG 


1 CG 


TACAIR 


1DDG 


1 CG 






HELO 


1 FIGHTER 
SEC 


1 STNGR 
DETCH 


1DDG 


1 CG 


TANKS 


1 COBRA 
SEC 


2 DDG 


1DDG 
1 CAS 


1 CAS 
1 RIFLE CO 


PATROL 

BOAT 


1 FFG 


1 COBRA 
SEC 


1 DDG 


1 CG 


PATROL 

BOAT 


1 CAS 








SUB 


1 FFG 








AS CM 


1 FIGHTER 
SEC 


1 DDG 


1 CG 





TASK 

NAME 


POSSIBLE 

RESOURCE 

COMBO 


POSSIBLE 

RESOURCE 

COMBO 


POSSIBLE 

RESOURCE 

COMBO 


POSSIBLE 

RESOURCE 

COMBO 


MEDIVAC 


1MED HELO 








HOLD 


1 RIFLE CO 








SILKWORM 

AIR 


1 FIGHTER 
SEC 


1 DDG 


1 CG 




SEAPORT 


2 RIFLE CO 
2 RIFLE CO 


2 RIFLE CO 
1 CG 


2 RIFLE CO 
1 COBRA SEC 


2 RIFLE CO 
1 CAS 


AIRPORT 


2 RIFLE CO 
2 RIFLE CO 


2 RIFLE CO 
1 CG 


2 RIFLE CO 
1 COBRA SEC 


2 RIFLE CO 
1 CAS 
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DDD Tutorial 



The DDD Graphical User interface 

The DDD graphical user interface displays a map on the left side of 
the screen which is a graphical representation of friendly and enemy 
platforms. Within the map, land is represented by squares which have a 
brown tint, and sea by squares which are white. The mouse commands 
listed in the next section will describe how friendly platforms on the map 
may be manipulated and how information on enemy platforms is obtained. 
The right half of the screen contains four buttons: 

• Start/Refresh: The Start button is used only at the beginning of a scenario to 
start all of the stations playing. Once the scenario has begun, the button 
changes to Refresh. Left clicking on the Refresh button redraws the map 
eliminating any undesired traces which may appear. 

• Zoom In: Allows the user to zoom in for a more detailed look at a particular 
section of the map. To zoom in, left click on the “Zoom In” button. Move the 
cursor over to map and left click at a point to the left or right of where the 
area of interest lies. While continuing to hold the left mouse button 
depressed, drag the cursor and a box will begin to appear showing the area 
which will be zoomed in on. 

• Zoom Out: Left clicking on this button returns the map to the previous map 
size. 

• Cancel: Left Clicking on the Cancel button allows the user to suspend an 
operation on an asset such as a move or an attack prior to completing the 
mission. 



The right half of the screen also contains a time bar. When a 
friendly platform or sub-platform is selected to perform an action (i.e. 
launch aircraft, attack), a white arrow will appear next to this bar showing 
the amount of time to complete this mission. The platform cannot perform 
any other action until this action is completed. In addition, above the time 
bar are several other pieces of information. The color of the stick man 
figure in a box shows the color of the platforms on the map which your 
station controls. Next to this box is the name of the station you are playing 
(i.e. CJTF 4, CJTG 4.1 , etc.) Below the box are two counters which 
display feedback on how well the entire team is doing on the scenario. 
The counter labeled mission starts at zero and increments as missions 
are accomplished. The counter labeled strength starts at 1 00 and 
decrements as your force strength is decreased. 

The lower portion of the screen contains two window dialog boxes. 
Close attention must be given to the window on the left as this box 
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displays messages between the various players which may require some 
action to be taken by your station. The right window can best be described 
as a confirmation window. Summaries of messages or actions performed 
by your station will appear in this window along with some messages 
about the status of other friendly platforms. Also, the very bottom of the 
screen below these two windows displays warning and error prompts. A 
beep will occur along with a warning or error message following any action 
performed by your station which is not allowed (i.e. Attempting to attack 
the enemy when your unit is out of range). 



Using the Mouse in DDD 

A standard three button mouse is used when running a scenario at 
each workstation. When clicking on an platform in DDD each mouse 
button serves a different function depending on whether the platform is 
friend or foe, and if friend whether or not the platform is owned or not 
owned by you. 

Left Mouse Button 

The left mouse button clicked on an platform will just select it. The 
left mouse button is also used to carry out options from a Right Mouse 
Menu covered on the next page. 

Middle Mouse Button 

When the middle button is clicked on an platform, the window 
presented depends on whether the platform is a (1) friendly platform or 
sub-platform or (2) enemy platform. If the platform is an enemy platform , 
a window appears which provides known information about the attributes 
of the platform. If a friendly platform is selected, a screen appears which 
displays the attributes of that platform or sub-platform. A friendly platform 
will show the attributes, ownership, and the number of all sub-platforms 
located on the platform is also shown. (Platforms are the major friendly 
platforms in the scenarios. Sub-platforms are platforms such as aircraft, 
Stinger detachments, engineering platoons, helicopters, etc. which are 
carried by a platform. The ownership of any sub-platform may or may not 
be the same as the owner of the platform it is being carried on). 

When a friendly platform is selected with the middle mouse button, 
the portion of the window where the sub-platforms are listed is used to 
launch or request launch of a sub-platform depending on where the sub- 
platform is located. There are three possible situations which can occur 
here: 
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1. Sub-platform needed to be launched is on a platform owned by you : In this 
case you can launch any sub-platform on your platform whether you own it or 
not. This is done by left clicking on the right arrow key in the line for the 
number of sub-platform(s) needed and then clicking OK. 

2. Sub-platform needed to be launched is owned by you, but is located on a 
platform which you do not own: 

a) In this case middle click on the platform where your sub-platform is 
located. 

b) Left click on the arrow located in the line of the sub-platform 
needed until the desired number of sub-platforms to be launched is 
set 

c) Left click on OK. A message will then be sent to the owner of the 
platform where your sub-platform is located requesting that it be 
launched. It is the responsibility of the person where your sub- 
platform resides to launch it. 

1. Sub-platform needed is not owned by you and is located on a platform not 
owned by you: In this case middle click on the platform where the sub- 
platform needed resides. Left click on the arrow on the line containing the 
sub-platform desired until the required number is set, and then left click on 
OK. A message will then be forwarded up your chain of command which must 
be acted upon by your immediate superior to obtain this sub-platform. 

The lower portion of this screen also offers options for displaying 
information on range for both sensors and weapons of a friendly platform 
against enemy ground, air, or sea assets. The sensor option will display 
four range rings around the platform: 

1) The outermost black ring represents the detection range. 

2) The next inner black ring represents the range at which measurements 
on the enemy can be made. 

3) The furthest inner black ring represents the visual detection range. 

4) The inner yellow ring represents the range at which the platform is 
vulnerable. 



The weapons option displays a single red ring around the platform 
which shows the effective range of its weapon. To display these range 
rings left click on either sensors, weapon, or both, and then left click what 
type of medium to display these for (air, ground, or sea). To turn the range 
rings off, middle click on the platform and left click on none. 

Right Mouse Button 
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The right mouse button will cause a menu to pop up. The following 
sections describe the options presented depending on the platform 
selected with the right mouse button. 

Friendly platform which you do not own: The menu that pops up will 
present the option of requesting the asset, forcing the transfer of the 
asset, or information on the asset. Explanations of these options follow: 

• Request (REQ): The menu requires input for who the request is to, and the 
urgency of the request. All items must be selected. When the choices are 
completed, a message is sent to the person selected if they are directly in 
your chain of command or up your chain of command where your superior 
must take action on the request. 

• Information (INFO): Same as middle clicking on the platform. 

Friendly platform which you own: This menu will allow the choices of 
Move, Pursue, Attack, Return, Transfer, or Information. An explanation of 
these options follow: 

• Move: Selecting move will cause a cross-hair type symbol to appear. Position 
this cross hair to the place the platform is desired to be moved and single 
click with the left mouse button. The platform will then move to this position. 
When it arrives there, it will stop until another command to move is given. 

• Pursue: Selecting pursue will cause the cursor to change to a finger. Place 
the finger on the enemy platform desired to be pursued, left click, and your 
platform will then move to pursue it. 

• Attack: When this option is selected a question mark will appear. Place the 
question mark on the platform. If in range to perform this action, a menu will 
then appear which shows the attributes of the platform selected to perform 
the attack and the attributes of the platform that the attack is to be performed 
on. The option is then given to carry out the mission or to cancel the 
assignment. 

• Coordinated Attack: If the platform selected to attack the enemy does 
not have enough combat power to accomplish the mission, a coordinated attack 
may be performed. It should be noted that the following explanations of how to 
do a coordinated attack will work only if all of the platforms are within attack 
range . 

• Coordinated Attack using Two Platforms: A coordinated attack using 
two platforms is accomplished by first selecting one of the two platforms to 
perform the coordinated attack with the left mouse button, and then right clicking 
on the second platform performing the attack. The menu will then pop up and 
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select the attack option. The cursor will then change to the question mark. Place 
it on the platform which is to be attacked and left click with the mouse. 

♦ Coordinated Attack using Three or More Platforms: To perform a 
coordinated attack with three or more platforms, left click on the first platform 
performing the attack. Then, while holding the shift key down on the keyboard, 
left click on all but one of the remaining platforms performing the attack. 

Release the shift key and right click on the final platform. The menu will pop up 
and select attack. The cursor will change to a question mark. Place it on the 
platform to be attacked and left click. 

A simultaneous attack by two or more players may be needed to bring 
sufficient combat power to bear. These should be coordinated using the voice 
net. 

• Return: This option may only be used for sub-platforms. Selecting this option 
will cause the sub-platform to return to the platform it originated from. The 
sub-platform will not move towards its originating platform, but instead will 
change to a box with a “x” in it to simulate returning to its originating platform. 
The return option has been disabled on some sub-platforms in the scenario. 

If one of these sub-platforms is directed to return, an error message will 
appear. 

• Information (INFO): Same as middle clicking on the platform. 

Enemy Platforms: The menu presented in this instance presents the 
options of Identify, Requesting Information, Transferring Information, 
Coordinating Action, Assigning, and Information. Explanations of these 
options follow: 

• Identify: This option is normally used to identify enemy platforms or s for 
which the identity is unknown. This will be readily apparent in a scenario as 
the first letter shown with the icon will be followed by a question mark. The 
first letter designates which medium the unknown contact operates in. “A?” 
denotes an unknown air contact; “G?” denotes an unknown ground contact; 
“S?” denotes an unknown sea contact. Selecting the identify option will cause 
a menu to pop up which shows the known attributes of the platform as seen 
by each player in the scenario. If a friendly platform having sensors capable 
of identifying the enemy platform is within sensor range the platform will be 
identified correctly. If not, the question mark will remain. This will be apparent 
by looking at the lower left hand column where the identity will be shaded 
from a list of possible identities. Click the fused button near the top left hand 
corner and then OK. The identity of the platform will then appear correctly on 
the map and its icon will change to its correct identity. 
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The following tables give descriptions of the two letter symbols which will be 
the options shown when identifying an platform: 



Unknown Ground 


Description 


? 


Unknown 


HL 


Ground mission of takina a hill 


AP 


Airport around mission 


SP 


Seaport around mission 


HD 


Holdina or occupvina around 


TK 


Takinq a qround mission 


AT 


Enemy artillery 


FG 


Enemy Froq launcher 


SWG 


Enemy Silkworm missile launcher 


TN 


Enemy tanks, troops, or vehicles 


NU 


Neutral 


MN 


Land Mines 



Unknown Air 


Description 


? 


Unknpwn 


AS 


Enemy attack aaainst ships 


AG 


Enemy attack aaainst around forces 


HH 


Enemy helo attack aaainst ships 


NU 


Neutral 


SWA 


Silkworm missile in fliqht 



Unknown Sea 


Description 


? 


ynknpwn 


MS 


mine? 


PB 


Enemy patrol boats 


SS 


Enemy submarines 


ML 


Enemy anti-ship cruise missiles 


NU 


Neutral 



• Request Information (REQ INFO): Selecting this option will cause a menu to 
pop up which allows you to select an other player, or all other players from 
whom you wish to obtain information on the enemy platform. Select the 
person(s) and click OK. A message will then be sent to the person(s) 
notifying them that this information is requested. 

• Transfer Information (XFR INFO): Selecting this option will cause a menu 
to pop up which allows you to select a particular individual, or all the players 
you wish information on the enemy platform to be sent to . Select the 
person(s) and click OK. A message will then be sent to the person(s) 
selected. 

• Coordinate Action (CRD ACTION): The use of this option allows messages 
to be sent between players concerning action requests, support, or intent 
against an enemy platform. When selected, a menu pops up displaying 
options for choosing who the message is to sent to and a list of messages 
which may be sent. The following messages may be sent: 

1. I plan to handle. 

2. I plan to support. 

3. I cannot handle. 

4. I cannot support. 

5. Can you handle ? 

6. Can you support ? 

Select the person the message is to be sent to, a message is to be sent, and 
click OK. The message will then be sent to the person selected. 

• Assign: This option may only be used if you are playing a position where 
you are superior to someone in the chain of command and may only be 
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directed at those people who are subordinate to you. This option will cause a 
question mark to appear. Place it on the enemy platform desired to be 
assigned and left click. A menu will then appear which allows selecting whom 
in the chain of command it is to be assigned to. Left click on the person 
desired to assign the mission to and click OK. A message will then be sent to 
that person notifying them they are responsible for taking care of the mission. 

• Information (INFO): Same as middle clicking on the platform. 

List of Platforms in the Scenario 



Terrain and task platforms 

The following shows representations of the icons which represents 
terrain or task platforms in the scenarios. 






Swamp: The swamp icon indicates areas which mechanized or 
infantry units should not traverse . Friendly units will not be destroyed by 
going into these areas, but total strength will be diminished. 



IHI Airfield: The airfield icon is the objective or mission to completed 
by CJTU 4.1.1. This airfield has attributes associated with it which must 
be compared to the attacking force attributes to determine if the 
necessary force is available. 



Port: The port is the objective or mission of CJTU 4.3.1 . It, 
like the airfields, also has attributes which must first be determined and 
compared to attacking forces attributes to determine if enough combat 
power can be brought to bare to achieve this objective. 



& 



Hill: The hill is commanding terrain between the port and airfield 
which must be captured by CJTU 4.3.1 . It is surrounded by swamps on 
both sides which means the only way of accomplishing this mission is by 
using AAAV or MV-22 sub-platforms. 

Task: The task icon has attributes which must first be identified and 
then a determination made as to the best asset available to complete this 
task. Tasks are normally used to represent enemy ground forces in a 
given location which must be eliminated. 



Medivac: The medivac icon is a mission which may appear after 
friendly ground platforms or sub-platforms engage enemy platforms . The 
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task has attributes which must be determined. The mission is completed 
by attacking it with the medivac helicopter (MED sub-platform). 



^ ^Hold: The hold icon may appear after completion of a mission 

(i.e. attacking the hill). If this occurs the asset used to perform the mission 
must remain in its current position and may not be used to perform any 
other mission. 



Enemy Assets 

The following section shows the icons which represent enemy 
forces that may or may not appear in a scenario. The text which follows 
each icon describes the enemy platforms capabilities and the friendly 
weapon of choice to use against it. 



Artillery: Enemy artillery pieces may pop up at various times. 

When they appear, they take approximately 5 minutes to set up before 
they are able to fire. The pieces are stored in reinforced concrete bunkers 
with the ammunition stored in deep underground bunkers. The methods 
by which enemy artillery may be suppressed is through the use of Naval 
Surface Fire support (NSFS), Close Air Support (CAS), or Cobra attack 
helicopter. NSFS can be accomplished by either the DDG or CG. Once 
the artillery pieces begin to move toward you, which simulates firing, you 
will be unable to attack them. 



<>- 



Mines: The enemy possesses the possibility of deploying both 
land and sea mines. If encountered and moved through by friendly forces 
the total effectiveness of these forces will be diminished. Sea based 
mines may only be cleared by the use of a mine clearing helicopter (MCM 
sub-platform) located on the ships. Land mines may only be cleared 
through the use of the engineering platoon (ENG sub-platform). 



Frog Missile sites: These sites are capable of launching short 
range missiles containing chemical munitions. The launchers take 
approximately 10 minutes to set up. Suppression must be done through 
the use of CAS aircraft carrying precision guided munitions located on the 
aircraft carrier, NSFS, or Cobra attack helicopter. 

Silkworm Missile Site: The enemy has placed silkworm missile 
sites in residential areas near the port. The appearance of a silkworm site 
requires visual confirmation through use of the Recon (Tarps sub- 
platform) prior to attacking the site. The site may only be destroyed by 
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using CAS carrying precision guided munitions, Cobra attack helicopters, 
or NSFS. 



Submarines: The enemy submarines are Alpha class nuclear 
powered submarines. They can only be destroyed using the FFG 
platform. 



Ship: The only ships the enemy possesses are fast patrol boats. 
These can be destroyed by using either the CG, DDG, or CAS aircraft. 



Helicopter: The enemy possesses Hind helicopters capable of 
carrying Exocet anti-ship missiles. The friendly asset capable of 
destroying them are the CG, DDG, Stinger detachment (SD sub-platform), 
and fighters (VF sub-platform). 



Aircraft: Enemy aircraft may launch attacks against the ships. 
Aircraft may be destroyed by using either the CG, DDG, Stinger 
detachment, or fighter aircraft located on the carrier. 



Tanks: Enemy tanks may be encountered along the road during the 
assaults on both the airfield and the port. The tanks can only be seen 
when within the detection range of friendly ground forces. If friendly forces 
move out of range the tank icon will disappear. Tanks can only be 
destroyed by using the Cobra attack helicopters, CAS aircraft, or NSFS 
from either the DDG or CG. 

<5> Unknown Enemy Platform: When this icon appears it must first be 
identified to determine what it is. The icon will have a letter designation 
followed by a “?”. “A” denotes unknown air; “G” denotes unknown ground; 
and “S” denotes unknown sea. The platform must be identified with a 
suitable friendly platform or sub-platform. Identification of unknown ground 
platforms may only be accomplished using the Recon aircraft (Tarps sub- 
platform) located on the carrier. 



Friendly Assets 



□ Friendly Platform Icon: This icon is used to represent friendly 
platforms in a scenario. The middle of the box will contain a letter to show 
the type of medium in which the platform operates. The letter “G” denotes 
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a ground asset; the letter “S’ denotes a sea asset; and the letter “A” 
denotes an air asset. An additional letter and number designator will be 
shown on the map above the icon for further identification (i.e. CVN-01). 
Platform icons are color coded to show ownership. 

<S> Friendly Sub-platform Icon: When launched from its parent 
platform a sub-platform will appear as a circle with a letter and number 
combination above it for further identification (i.e. MCM-01). The middle of 
the circle will contain a letter to show the type of medium in which the 
platform operates. The letter “G” denotes a ground asset; the letter “S’ 
denotes a sea asset; and the letter “A” denotes an air asset. Sub-platform 
icons are also color coded to show ownership. 



Friendly Platform/Sub-platform Busy Icon: When a platform or 
sub-platform is directed to perform some mission such as attacking; 
transfer ownership between players; launch a sub-platform; or when a 
sub-platform is directed to return, the icon will change to a box with a “x” in 
it. The platform or sub-platform cannot be directed to perform any other 
function until this mission is completed. At the end of the mission it will 
change back to its previous form. 



Chain of Command 

The following organizational structure will be used in the scenarios. 




CJTF 4: Overall commander of the operation as delineated in the 
oporder. CJTF 4 commands the Recon tarps sub-platform in the scenario. 
Units controlled by CJTF in a scenario will be black in color. 

CJTG 4.1 : Reports directly to CJTF 4 in the chain of command. 
Commands a LHA, a LPD, and a DDG. ONLY THE LPD WILL BE 
SHOWN ON THE COMMON OPERATIONSL DISPLAY. ALL SUB- 
PLATFORMS WILL BE LAUNCHED FROM THE LPD DURING GAME 
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PLAY. Also commands two AH-1 Cobra sub-platforms, one UH-1 
Medivac, and one MH-53 MCM. Responsible for coordination of JTU 

4.1.1 in attacking Blue Beach. Units controlled by CJTG 4.1 will be green 
in color. 

CJTG 4.2: Reports directly to CJTF 4 in the chain of command. 
Commands one CG, the CV, two FFGs, eight fighter sections, and eight 
CAS sections. Units controlled by CJTG 4.2 will be blue in color. 

CJTG 4.3: Reports directly to CJTF 4 in the chain of command. 
Commands a DDG, a LHA, and a LPD. ONLY THE LHA WILL BE 
SHOWN ON THE COMMON OPERATIONAL DISPLAY. ALL SUB- 
PLATFORMS WILL BE LAUNCHED FROM THE LHA DURING GAME 
PLAY. Also commands two AH-1 Cobra sub-platforms, one UH-1 
MEDIVAC, and one MH-53 MCM. Responsible for coordination of JTU 

4.3.1 in attacking Red Beach, commanding terrain, and taking the port. 
Units controlled by CJTG 4.3 are magenta in color. 

CJTU 4.1.1: Reports directly to CJTG 4.1 in the chain of command. 
Commands three rifle companies, two AAAV mounted platoons, 
Engineering platoon for land mine clearing, a Stinger detachment, and 
one MV-22 Osprey flight. . One AAAV or one MV-22 carries one rifle 
company ashore. Responsible for assaulting Blue Beach and taking the 
airfield. Units controlled by CJTU 4.1 .1 will be red in color. 

CJTU 4.3.1 : Reports directly to CJTG 4.3 in the chain of command. 
Commands three rifle companies, a AAAV mounted platoon, Engineering 
platoon, a Stinger detachment, and two MV-22 Osprey flights. One AAAV 
or one MV-22 carries one rifle company ashore. Responsible for 
assaulting Red Beach, the commanding terrain, and taking the port. Units 
controlled by CJTU 4.3.1 will be orange in color. 
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Platform 


Owner 


Sub-platform 

(QTY) 


Capability 


Description 


LHA-01 


CJTG 4.1 


AH1, MED1, 
MCM1, MV1 




Large Deck amphib to support Blue Beach 
assault 


LPD-01 


CJTG 4.1 


COI, ENG1, 
SD1, AAA VI 




Troop carrier amphib to support Blue Beach 
assault 


DDG-01 


CJTG 4.1 




NSFS AAW 


Destroyer 


CVN-02 


CJTG 4.2 


VF, Recon, 
CAS 




Aircraft Carrier 


CG-02 


CJTG 4.2 




NSFS AAW 


Cruiser 


FFG-002A 


CJTG 4.2 




ASW 


Frigate 


FFG-002B 


CJTG 4.2 




ASW 


Frigate 


LHA-03 


CJTG 4.3 


AH3, MED3, 
MCM3, MV3 




Large Deck amphib to support Red Beach 
assault 


LPD-03 


CJTG 4.3 


C03, ENG3, 
SD3, AAAV3 




Troop carrier amphib to support Red Beach 
assault 


DDG-03 


CJTG 4.3 




NSFS AAW 


Destroyer 


Sub- 

Platform 


Owner 


Location 


Quantity 


Capability 


Recon 


CJTF4 


CVN-02 


1 


F-14 Tarps for Recon only 


AH1 


CJTG 4.1 


LHA-01 


2 


Cobra Attack Helicopter 


MED1 


CJTG 4.1 


LHA-01 


1 


UH-1 Medivac 


MCM 


CJTG 4.1 


LHA-01 


1 


Helicopter for clearing sea based mines 


VF 


CJTG 4.2 


CVN-02 


8 


F-14 fighers for CAP 


CAS 


CJTG 4.2 


CVN-02 


8 


F/A-18 equiped with precision guided munitions 


AH3 


CJTG 4.3 


LHA-03 


2 


Cobra Attack Helicopter 


MED3 


CJTG 4.3 


LHA-03 


1 


UH-1 Medivac 


MCM3 


CJTG 4.3 


LHA-03 


1 


Helicopter for clearing sea based mines 


COI 


CJTU 4.1.1 


LPD-01 


3 


Rifle Companies 


AAA VI 


CJTU 4.1.1 


LPD-01 


2 


AAAV mounted platoon 


ENG1 


CJTU 4.1.1 


LPD-01 


1 


Engineering platoon for clearing land mines 


SD1 


CJTU 4.1.1 


LPD-01 


1 


Stinger Detachment for Anti-Air Defense 


MV1 


CJTU 4.1.1 


LHA-01 


1 


MV-22 Osprey 


C03 


CJTU 4.3.1 


LPD-03 


3 


Rifle Companies 


AAAV3 


CJTU 4.3.1 


LPD-03 


1 


AAAV mounted platoon 


ENG3 


CJTU 4.3.1 


LPD-03 


1 


Engineering platoon for clearing land mines 


SD3 


CJTU 4.3.1 


LPD-03 


1 


Stinger Detachment for Anti-Air Defense 


MV3 


CJTU 4.3.1 


LHA-03 


2 


MV-22 Osprey 
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DDD Tutorial 



The DDD Graphical User interface 

The DDD graphical user interface displays a map on the left side of 
the screen which is a graphical representation of friendly and enemy 
platforms. Within the map, land is represented by squares which have a 
brown tint, and sea by squares which are white. The mouse commands 
listed in the next section will describe how friendly platforms on the map 
may be manipulated and how information on enemy platforms is obtained. 
The right half of the screen contains four buttons: 

• Start/Refresh: The Start button is used only at the beginning of a scenario to 
start all of the stations playing. Once the scenario has begun, the button 
changes to Refresh. Left clicking on the Refresh button redraws the map 
eliminating any undesired traces which may appear. 

• Zoom In: Allows the user to zoom in for a more detailed look at a particular 
section of the map. To zoom in, left click on the “Zoom In” button. Move the 
cursor over to map and left click at a point to the left or right of where the 
area of interest lies. While continuing to hold the left mouse button 
depressed, drag the cursor and a box will begin to appear showing the area 
which will be zoomed in on. 

• Zoom Out: Left clicking on this button returns the map to the previous map 
size. 

• Cancel: Left Clicking on the Cancel button allows the user to suspend an 
operation on an asset such as a move or an attack prior to completing the 
mission. 



The right half of the screen also contains a time bar. When a 
friendly platform or sub-platform is selected to perform an action (i.e. 
launch aircraft, attack), a white arrow will appear next to this bar showing 
the amount of time to complete this mission. The platform cannot perform 
any other action until this action is completed. In addition, above the time 
bar are several other pieces of information. The color of the stick man 
figure in a box shows the color of the platforms on the map which your 
station controls. Next to this box is the name of the station you are playing 
(i.e. CJTF 4, CJTG 4.1, etc.) Below the box are two counters which 
display feedback on how well the entire team is doing on the scenario. 

The counter labeled mission starts at zero and increments as missions 
are accomplished. The counter labeled strength starts at 100 and 
decrements as your force strength is decreased. 

The lower portion of the screen contains two window dialog boxes. 
Close attention must be given to the window on the left as this box 
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displays messages between the various players which may require some 
action to be taken by your station. The right window can best be described 
as a confirmation window. Summaries of messages or actions performed 
by your station will appear in this window along with some messages 
about the status of other friendly platforms. Also, the very bottom of the 
screen below these two windows displays warning and error prompts. A 
beep will occur along with a warning or error message following any action 
performed by your station which is not allowed (i.e. Attempting to attack 
the enemy when your unit is out of range). 



Using the Mouse in DDD 

A standard three button mouse is used when running a scenario at 
each workstation. When clicking on an platform in DDD each mouse 
button serves a different function depending on whether the platform is 
friend or foe, and if friend whether or not the platform is owned or not 
owned by you. 

Left Mouse Button 

The left mouse button clicked on an platform will just select it. The 
left mouse button is also used to carry out options from a Right Mouse 
Menu covered on the next page. 

Middle Mouse Button 

When the middle button is clicked on an platform, the window 
presented depends on whether the platform is a (1) friendly platform or 
sub-platform or (2) enemy platform. If the platform is an enemy platform , 
a window appears which provides known information about the attributes 
of the platform. If a friendly platform is selected, a screen appears which 
displays the attributes of that platform or sub-platform. A friendly platform 
will show the attributes, ownership, and the number of all sub-platforms 
located on the platform is also shown. (Platforms are the major friendly 
platforms in the scenarios. Sub-platforms are platforms such as aircraft, 
Stinger detachments, engineering platoons, helicopters, etc. which are 
carried by a platform. The ownership of any sub-platform may or may not 
be the same as the owner of the platform it is being carried on). 

When a friendly platform is selected with the middle mouse button, 
the portion of the window where the sub-platforms are listed is used to 
launch or request launch of a sub-platform depending on where the sub- 
platform is located. There are three possible situations which can occur 
here: 
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1. Sub-platform needed to be launched is on a platform owned bv you : In this 
case you can launch any sub-platform on your platform whether you own it or 
not. This is done by left clicking on the right arrow key in the line for the 
number of sub-platform(s) needed and then clicking OK. 

2. Sub-platform needed to be launched is owned bv you, but is located on a 
platform which you do not own: 

a) In this case middle click on the platform where your sub-platform is 
located. 

b) Left click on the arrow located in the line of the sub-platform 
needed until the desired number of sub-platforms to be launched is 
set 

c) Left click on OK. A message will then be sent to the owner of the 
platform where your sub-platform is located requesting that it be 
launched. It is the responsibility of the person where your sub- 
platform resides to launch it. 

1. Sub-platform needed is not owned bv you and is located on a platform not 
owned bv you: In this case middle click on the platform where the sub- 
platform needed resides. Left click on the arrow on the line containing the 
sub-platform desired until the required number is set, and then left click on 
OK. A message will then be forwarded up your chain of command which must 
be acted upon by your immediate superior to obtain this sub-platform. 

The lower portion of this screen also offers options for displaying 
information on range for both sensors and weapons of a friendly platform 
against enemy ground, air, or sea assets. The sensor option will display 
four range rings around the platform: 

1) The outermost black ring represents the detection range. 

2) The next inner black ring represents the range at which measurements 
on the enemy can be made. 

3) The furthest inner black ring represents the visual detection range. 

4) The inner yellow ring represents the range at which the platform is 
vulnerable. 



The weapons option displays a single red ring around the platform 
which shows the effective range of its weapon. To display these range 
rings left click on either sensors, weapon, or both, and then left click what 
type of medium to display these for (air, ground, or sea). To turn the range 
rings off, middle click on the platform and left click on none. 

Right Mouse Button 



142 



The right mouse button will cause a menu to pop up. The following 
sections describe the options presented depending on the platform 
selected with the right mouse button. 

Friendly platform which you da not own: The menu that pops up will 
present the option of requesting the asset, forcing the transfer of the 
asset, or information on the asset. Explanations of these options follow: 

• Request (REQ): The menu requires input for who the request is to, and the 
urgency of the request. All items must be selected. When the choices are 
completed, a message is sent to the person selected if they are directly in 
your chain of command or up your chain of command where your superior 
must take action on the request. 

• Information (INFO): Same as middle clicking on the platform. 

Friendly platform which you own: This menu will allow the choices of 
Move, Pursue, Attack, Return, Transfer, or Information. An explanation of 
these options follow: 

• Move: Selecting move will cause a cross-hair type symbol to appear. Position 
this cross hair to the place the platform is desired to be moved and single 
click with the left mouse button. The platform will then move to this position. 
When it arrives there, it will stop until another command to move is given. 

• Pursue: Selecting pursue will cause the cursor to change to a finger. Place 
the finger on the enemy platform desired to be pursued, left click, and your 
platform will then move to pursue it. 

• Attack: When this option is selected a question mark will appear. Place the 
question mark on the platform. If in range to perform this action, a menu will 
then appear which shows the attributes of the platform selected to perform 
the attack and the attributes of the platform that the attack is to be performed 
on. The option is then given to carry out the mission or to cancel the 
assignment. 

• Coordinated Attack: If the platform selected to attack the enemy does 
not have enough combat power to accomplish the mission, a coordinated attack 
may be performed. It should be noted that the following explanations of howto 
do a coordinated attack will work only if all of the platforms are within attack 
range . 

• Coordinated Attack using Two Platforms: A coordinated attack using 
two platforms is accomplished by first selecting one of the two platforms to 
perform the coordinated attack with the left mouse button, and then right clicking 
on the second platform performing the attack. The menu will then pop up and 
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select the attack option. The cursor will then change to the question mark. Place 
it on the platform which is to be attacked and left click with the mouse. 

• Coordinated Attack using Three or More Platforms: To perform a 
coordinated attack with three or more platforms, left click on the first platform 
performing the attack. Then, while holding the shift key down on the keyboard, 
left click on all but one of the remaining platforms performing the attack. 

Release the shift key and right click on the final platform. The menu will pop up 
and select attack. The cursor will change to a question mark. Place it on the 
platform to be attacked and left click. 

A simultaneous attack by two or more players may be needed to bring 
sufficient combat power to bear. These should be coordinated using the voice 
net. 

• Return: This option may only be used for sub-platforms. Selecting this option 
will cause the sub-platform to return to the platform it originated from. The 
sub-platform will not move towards its originating platform, but instead will 
change to a box with a “x” in it to simulate returning to its originating platform. 
The return option has been disabled on some sub-platforms in the scenario. 

If one of these sub-platforms is directed to return, an error message will 
appear. 

• Information (INFO): Same as middle clicking on the platform. 

Enemy Platforms: The menu presented in this instance presents the 
options of Identify, Requesting Information, Transferring Information, 
Coordinating Action, Assigning, and Information. Explanations of these 
options follow: 

• Identify: This option is normally used to identify enemy platforms or s for 
which the identity is unknown. This will be readily apparent in a scenario as 
the first letter shown with the icon will be followed by a question mark. The 
first letter designates which medium the unknown contact operates in. “A?” 
denotes an unknown air contact; “G?” denotes an unknown ground contact; 
“S?” denotes an unknown sea contact. Selecting the identify option will cause 
a menu to pop up which shows the known attributes of the platform as seen 
by each player in the scenario. If a friendly platform having sensors capable 
of identifying the enemy platform is within sensor range the platform will be 
identified correctly. If not, the question mark will remain. This will be apparent 
by looking at the lower left hand column where the identity will be shaded 
from a list of possible identities. Click the fused button near the top left hand 
corner and then OK. The identity of the platform will then appear correctly on 
the map and its icon will change to its correct identity. 
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The following tables give descriptions of the two letter symbols which will be 
the options shown when identifying an platform: 



Unknown Ground 


Description 


9 


ynknpwn 


HL 


Ground mission of takina a hill 


AP 


AirDort around mission 


SP 


Seaport around mission 


HD 


Holdina or occuDvina around 


TK 


Taking a qround mission 


AT 


Enemy artillery 


FG 


Enemy Froq launcher 


SWG 


Enemy Silkworm missile launcher 


TN 


Enemv tanks, trooos. or vehicles 


NU 


Neutral 


MN 


Land Mines 



Unknown Air 


Description 


? 


ynknqwn 


AS 


Enemv attack aaainst ships 


AG_. 


Enemv attack aaainst around forces 


HH 


Enemv helo attack aaainst ships 


NU 


Neutral 


SWA 


Silkworm missile in flight 



Unknown Sea 


Description 


? 


Unknown 


MS 


Sea mines 


PB 


Enemv oatrql bo^tts 


SS 


Enemy submarines 


ML 


Enemv anti-ship cruise missiles 


NU 


Neutral 



• Request Information (REQ INFO): Selecting this option will cause a menu to 
pop up which allows you to select an other player, or all other players from 
whom you wish to obtain information on the enemy platform. Select the 
person(s) and click OK. A message will then be sent to the person(s) 
notifying them that this information is requested. 

• Transfer Information (XFR INFO): Selecting this option will cause a menu 
to pop up which allows you to select a particular individual, or all the players 
you wish information on the enemy platform to be sent to . Select the 
person(s) and click OK. A message will then be sent to the person(s) 
selected. 

• Coordinate Action (CRD ACTION): The use of this option allows messages 
to be sent between players concerning action requests, support, or intent 
against an enemy platform. When selected, a menu pops up displaying 
options for choosing who the message is to sent to and a list of messages 
which may be sent. The following messages may be sent: 

1. I plan to handle. 

2. I plan to support. 

3. I cannot handle. 

4. I cannot support. 

5. Can you handle ? 

6. Can you support ? 

Select the person the message is to be sent to, a message is to be sent, and 
click OK. The message will then be sent to the person selected. 

• Assign: This option may only be used if you are playing a position where 
you are superior to someone in the chain of command and may only be 
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directed at those people who are subordinate to you. This option will cause a 
question mark to appear. Place it on the enemy platform desired to be 
assigned and left click. A menu will then appear which allows selecting whom 
in the chain of command it is to be assigned to. Left click on the person 
desired to assign the mission to and click OK. A message will then be sent to 
that person notifying them they are responsible for taking care of the mission. 

• Information (INFO): Same as middle clicking on the platform. 

List of Platforms in the Scenario 



Terrain and task platforms 

The following shows representations of the icons which represents 
terrain or task platforms in the scenarios. 






Swamp: The swamp icon indicates areas which mechanized or 
infantry units should not traverse . Friendly units will not be destroyed by 
going into these areas, but total strength will be diminished. 

N Airfield: The airfield icon is the objective or mission to completed 
by CJTG 4.3. This airfield has attributes associated with it which must be 
compared to the attacking force attributes to determine if the necessary 
force is available. 



Tf- Port: The port is the objective or mission of CJTG 4.1 . It, 

like the airfields, also has attributes which must first be determined and 
compared to attacking forces attributes to determine if enough combat 
power can be brought to bare to achieve this objective. 



/t 



Hill: The hill is commanding terrain between the port and airfield 
which must be captured by CJTU 4.1. It is surrounded by swamps on both 
sides which means the only way of accomplishing this mission is by using 
the AAAV or MV-22 sub-platforms. 

Task: The task icon has attributes which must first be identified and 
then a determination made as to the best asset available to complete this 
task. Tasks are normally used to represent enemy ground forces in a 
given location which must be eliminated. 



Medivac: The medivac icon is a mission which may appear after 
friendly ground platforms or sub-platforms engage enemy platforms . The 
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task has attributes which must be determined. The mission is completed 
by attacking it with the medivac helicopter (MED sub-platform). 



The hold icon may appear after completion of a mission 
(i.e. attacking the hill). If this occurs the asset used to perform the mission 
must remain in its current position and may not be used to perform any 
other mission. 



Enemy Assets 



The following section shows the icons which represent enemy 
forces that may or may not appear in a scenario. The text which follows 
each icon describes the enemy platforms capabilities and the friendly 
weapon of choice to use against it. 



Artillery: Enemy artillery pieces may pop up at various times. 
When they appear, they take approximately 5 minutes to set up before 
they are able to fire. The pieces are stored in reinforced concrete bunkers 
with the ammunition stored in deep underground bunkers. The methods 
by which enemy artillery may be suppressed is through the use of Naval 
Surface Fire support (NSFS), Close Air Support (CAS), or Cobra attack 
helicopter. NSFS can be accomplished by either the DDG or CG. Once 
the artillery pieces begin to move toward you, which simulates firing, you 
will be unable to attack them. 



Mines: The enemy possesses the possibility of deploying both 
land and sea mines. If encountered and moved through by friendly forces 
the total effectiveness of these forces will be diminished. Sea based 
mines may only be cleared by the use of a mine clearing helicopter (MCM 
sub-platform) located on the ships. Land mines may only be cleared 
through the use of the engineering platoon (ENG sub-platform). 



Frog Missile sites: These sites are capable of launching short 
range missiles containing chemical munitions. The launchers take 
approximately 10 minutes to set up. Suppression must be done through 
the use of CAS aircraft carrying precision guided munitions located on the 
aircraft carrier, NSFS, or Cobra attack helicopter. 



Silkworm Missile Site: The enemy has placed silkworm missile 
sites in residential areas near the port. The appearance of a silkworm site 
requires visual confirmation through use of the Recon (Tarps sub- 
platform) prior to attacking the site. The site may only be destroyed by 
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using CAS carrying precision guided munitions, Cobra attack helicopters, 
orNSFS. 



Submarines: The enemy submarines are Alpha class nuclear 
powered submarines. They can only be destroyed using the FFG 
platform. 



Ship: The only ships the enemy possesses are fast patrol boats. 
These can be destroyed by using either the CG, DDG, or CAS aircraft. 



Helicopter: The enemy possesses Hind helicopters capable of 
carrying Exocet anti-ship missiles. The friendly asset capable of 
destroying them are the CG, DDG, Stinger detachment (SD sub-platform), 
and fighters (VF sub-platform). 



Aircraft: Enemy aircraft may launch attacks against the ships. 
Aircraft may be destroyed by using either the CG, DDG, Stinger 
detachment, or fighter aircraft located on the carrier. 



Tanks: Enemy tanks may be encountered along the road during the 
assaults on both the airfield and the port. The tanks can only be seen 
when within the detection range of friendly ground forces. If friendly forces 
move out of range the tank icon will disappear. Tanks can only be 
destroyed by using the Cobra attack helicopters, CAS aircraft, or NSFS 
from either the DDG or CG. 



sy Unknown Enemy Platform: When this icon appears it must first be 
identified to determine what it is. The icon will have a letter designation 
followed by a “?”. “A” denotes unknown air; “G” denotes unknown ground; 
and “S” denotes unknown sea. The platform must be identified with a 
suitable friendly platform or sub-platform. Identification of unknown ground 
platforms may only be accomplished using the Recon aircraft (Tarps sub- 
platform) located on the earner. 



Friendly Assets 



□ Friendly Platform Icon: This icon is used to represent friendly 
platforms in a scenario. The middle of the box will contain a letter to show 
the type of medium in which the platform operates. The letter “G” denotes 
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a ground asset; the letter “S’ denotes a sea asset; and the letter “A” 
denotes an air asset. An additional letter and number designator will be 
shown on the map above the icon for further identification (i.e. CVN-01). 
Platform icons are color coded to show ownership. 

<S> Friendly Sub-platform Icon: When launched from its parent 
platform a sub-platform will appear as a circle with a letter and number 
combination above it for further identification (i.e. MCM-01). The middle of 
the circle will contain a letter to show the type of medium in which the 
platform operates. The letter “G” denotes a ground asset; the letter “S’ 
denotes a sea asset; and the letter “A” denotes an air asset. Sub-platform 
icons are also color coded to show ownership. 



Friendly Platform/Sub-platform Busy Icon: When a platform or 
sub-platform is directed to perform some mission such as attacking; 
transfer ownership between players; launch a sub-platform; or when a 
sub-platform is directed to return, the icon will change to a box with a “x” in 
it. The platform or sub-platform cannot be directed to perform any other 
function until this mission is completed. At the end of the mission it will 
change back to its previous form. 



Chain of Command 

The following organizational structure will be used in the scenarios. 
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CJTF 4: Overall commander of the operation as delineated in the 
oporder. CJTF 4 commands the aircraft carrier, CAS aircraft, and Recon 
tarps sub-platform in the scenario. Units controlled by CJTF in a scenario 
will be black in color. 

CJTG 4.1 : Reports directly to CJTF 4 in the chain of command. 
Commands three rifle companies, a LHA, and a LPD. ONLY THE LPD 
WILL BE SHOWN ON THE COMMON OPERATIONSL DISPLAY. ALL 
SUB-PLATFORMS WILL BE LAUNCHED FROM THE LPD DURING 
GAME PLAY. Also commands a AAAV mounted platoon, two MV-22 
flights, and a Stinger Detachment. One AAAV or one MV-22 carries one 
rifle company ashore. Responsible for attacking Red Beach, commanding 
terrain, and taking the Port. Units controlled by CJTG 4.1 will be green in 
color. 

CJTG 4.2: Reports directly to CJTF 4 in the chain of command. 
Responsible for the detachment of two AH-1 Cobras. CJTG 4.2 will 
coordinate the actions of CJTU 4.2.1 and CJTU 4.2.2. Units controlled by 
CJTG 4.2 will be blue in color. 

CJTG 4.3: Reports directly to CJTF 4 in the chain of command. 
Commands three rifle companies, a LHA, and a LPD. ONLY THE LHA 
WILL BE SHOWN ON THE COMMON OPERATIONAL DISPLAY. ALL 
SUB-PLATFORMS WILL BE LAUNCHED FROM THE LHA DURING 
GAME PLAY. Also commands two AAAV mounted platoons, a MV-22 
flight, a Stinger detachment, and two AH-1 Cobra attack helicopters. . 

One AAAV or one MV-22 carries one rifle company ashore. Responsible 
for attacking Blue Beach and taking the airfield. Units controlled by CJTG 
4.3 are magenta in color. 

CJTU 4.2.1 : Reports directly to CJTG 4.2 in the chain of command. 
Commands two DDGs and the CG. Additionally commands an 
Engineering platoon, a MH-53 MCM, and a UH-1 MEDIVAC. 

Responsible for assisting CJTG 4.1 and CJTG 4.3 in the assault. Units 
controlled by CJTU 4.1.1 will be red in color. 

CJTU 4.3.1 : Reports directly to CJTG 4.2 in the chain of command. 
Commands two FFGs and 8 sections of fighters for CAP. Additionally 
commands an Engineering platoon, a MH-53 MCM, and a UH-1 
MEDICAC. Responsible for ASW and supporting CJTG 4.1 and CJTG 
4.3 in the assault. Units controlled by CJTU 4.3.1 will be orange in color. 
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Platform 


Owner 


Sub-platform (QTY) 


Capability 


Description 


CVN-01 


CJTF4 


Recon, VF, CAS 




Aircraft Carrier 


LHA-01 


CJTG 4.1 


AH1, MED1, MCM1, MV1 




Large Deck amphib to support Red 
Beach assault 


LPD-01 


CJTG 4.1 


COI, ENG1, SD1, AAAV1 




Troop carrier amphib to support 
Red Beach assault 


LHA-03 


CJTG 4.3 


AH3, MED3, MCM3, MV3 




Large Deck amphib to support Blue 
Beach assault 


LPD-03 


CJTG 4.3 


C03, ENG3, SD3, AAAV3 




Troop carrier amphib to support 
Blue Beach assault 


DDG-01 A 


CJTU 4.2.1 




NSFS AAW 


Destroyer 


DDG-01B 


CJTU 4.2.1 




NSFS AAW 


Destroyer 


CG-01 


CJTU 4.2.1 




NSFS AAW 


Cruiser 


FFG-02A 


CJTU 4.2.2 




ASW 


Frigate 


FFG-02B 


CJTU 4.2.2 




ASW 


Frigate 


Sub-Platform 


Owner 


Location 


Quantity 


Capability 


Recon 


CJTF4 


CVN-01 


1 


F-14 Tarps for Recon only 


CAS 


CJTF4 


LHA-01 


8 


F/A-18 equiped with precision 
guided munitions 


COI 


CJTG 4.1 


LPD-01 


3 


Rifle Companies 


AAAV1 


CJTG 4.1 


LPD-01 


1 


AAAV mounted platoon 


MV1 


CJTG 4.1 


LHA-01 


2 


MV-22 Osprey 


SD1 


CJTG 4.2 


LPD-01 


1 


Stinger Detachment for Anti-Air 
Defense 


AH1 


CJTG 4.2 


LHA-01 


2 


Cobra Attack Helicopter 


C03 


CJTG 4.3 


LPD-03 


3 


Rifle Companies 


AAAV3 


CJTG 4.3 


LPD-03 


2 


AAAV mounted platoon 


MV3 


CJTG 4.3 


LHA-03 


1 


MV-22 Osprey 


SD3 


CJTG 4.3 


LPD-01 


1 


Stinger Detachment for Anti-Air 
Defense 


AH3 


CJTG 4.3 


LHA-03 


2 


Cobra Attack Helicopter 


ENG1 


CJTU 4.2.1 


LPD-01 


1 


Engineering platoon for clearing 
land mines 


MCM1 


CJTU 4.2.1 


LHA-01 


1 


Helicopter for clearing sea based 
mines 


MED1 


CJTU 4.2.1 


LHA-01 


1 


UH-1 MEDIVAC 


VF 


CJTU 4.2.2 


CVN-01 


8 


F-14 fighters for CAP 


ENG3 


CJTU 4.2.2 


LPD-03 


1 


Engineering platoon for clearing 
land mines 


MCM3 


CJTU 4.2.2 


LHA-03 


1 


Helicopter for clearing sea based 
mines 


MED3 


CJTU 4.2.2 


LHA-03 


1 


UH-1 MEDIVAC 
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APPENDIX B. DATA COLLECTION FORMS AND QUESTIONAIRES 



Appendix B contains the forms used during the DDD-III runs and the planning sessions to 
record observations and the results of the players planning sessions and the questionaires the 
players were asked complete at the end of the trials. 



Player Questionaire 154 

A2C2 Post-Planning Assessment: Observer Rating Form 157 

A2C2 Planning Organizer and Products Booklet 159 
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A2C2 EXPERIMENT POST-PLANNING QUESTIONAIRE 



Name: 




Position: 


Team ID: 


Planning Session: 


Date: 



This questionaire is comprised of three parts. The first part asks you to speculate about 
changes that would be required in the organization and architecture you designed if different 
priorities were in effect. The second part asks you to rate several attributes of high priority tasks. 
The third part inquires about aspects of the planning and designing products. 

PART I: Different Priorities 



1 . If you were instructed to plan and design your organization and architecture to cope with a 
very short time period and minimize the amount of time necessary to accomplish the revised 
mission after the event, what changes would you make to the organization and architecture you 
devise? Describe these changes (if any) briefly. 



2. What if you were asked to minimize the amount of assets and resources needed to complete 
the mission, what changes would you make to the organization and architecture you devise? 
Describe these changes (if any) briefly. 



3. What if you were asked to minimize the amount of risk involved in the operation, what 
changes would you make to the organization and architecture you devise? Describe these changes 
(if any) briefly. 
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PART 2: Attributes of High Priority Tasks 



examine the plan you have just completed and select the three (3) highest priority (i.e. 
most critical) tasks that must be completed to accomplish the mission. Write a descriptive name 
for the highest priority task under Task 1, the next highest priority task under Task 2, etc. Some 
tasks require a short amount of time to complete, but their execution is critical to the mission. 
Other tasks are important because they demand a great deal of time to complete. Still other tasks 
are not critical unless they are not done, then they become very critical because terrible things can 
happen. Consider the different reasons the tasks you selected are critical and rate each of these 
tasks on the scales below. 



Task 1 


Task 2 


Task 3 








Time spent - The amount of time spent, relative to other tasks in the mission. 


i i i i i i 


I I I I I I 


I I I I I I 


a little a lot 


a little a lot 


a little a lot 


Task difficulty - How difficult it is to perform the task, relative to all other tasks in the mission. 


i i i i i i 


i i i i i i 


i i i i i i 


a little a lot 


a little a lot 


a little a lot 


Task criticality - Degree to which incorrect performance of the task would result in negative consequences. 


i i i i i i 


i i i i i i 


i i i i i i 


a little a lot 


a little a lot 


a little a lot 


Task responsibility - Degree of direct, constant personnel responsibility for completing the task. 


i i i i i i 


i i i i i i 


i i i i i i 


a little a lot 


a little a lot 


a little a lot 


Difficulty to learn task - The amount of time and effort that is required to learn to mange the task, relative to all 


other tasks in the mission. 






i i i i i i 


I I I I I I 


i i i i i i 


a little a lot 


a little a lot 


a little a lot 


Overall importance - The overall importance of the task, relative to all other tasks in the mission. 


i i i i i i 


i i i i i i 


I I I I I I 


a little a lot 


a little a lot 


a little a lot 
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PART 3: Rationale 



1. Consider the original organization and architecture you used when performing on the DDD-III 
simulation and compare it to the organization and architecture you have devised to address the 
event. Rate the degree of change or adaption of the new organization and architecture to cope 
with the event. 



II I 213 14 15 16 17 I 

very little a great deal 

2. How confident are you that the organization and architecture you have devised will accomplish 
the revised mission caused by the event? 

II I 213 14 15 16 17 I 

very little a great deal 

3. How adequate was the amount of resources available to deal with the event and the remainder 
of the original mission? 

II 1213 1415 1617 I 

not adequate very adequate 

4. How deficient was the original organization and architecture PRIOR to the event? 

II 1213 14 15 16 17 I 

very little a great deal 

5. How deficient was the original organization and architecture AFTER the event? 

II 1213 1415 1617 I 



very little 



a great deal 



ADAPTIVE ARCHITECTURES FOR COMMAND AND CONTROL (A2C2) 
POST-PLANNING ASSESSMENT: OBSERVER RATING FORM 



Team ID: Date: Observer: 

Instructions for Post-Planning Assessment 

Please assess the post-planning behavior of the team for the following activities using the 
scales provided. Base the rating on what you heard and observed not on what you guess and 
think. 

1. To what extent did the team strive to understand the new situation/mission created by the 
trigger event? 



Very Little 1 2 3 4 5 6 7 A Great Deal 



Comments: 



2. How well did the team appear to understand the new/situation/mission created by the trigger 
event? 



Not Well 1 2 3 4 5 6 7 Very Well 



Comments: 



3. How organized and focused did the team appear to be while working the planning task? 

Unfocused 1 2 3 4 5 6 7 Very focused 

And Chaotic And Organized 



Comments: 



4. To what extent did the team address workload disparities among the organizational nodes? 

Very Little 1 2 3 4 5 6 7 A Great Deal 



Comments: 
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5. To what extent did the team strive to produce an architecture (organizational structure) that 
distributed and equalized the workload among the organizational nodes? 

Very Little 1 2 3.4 5 6 7 A Great Deal 



Comments: 



6. Did the team strive to produce a more traditional or more untraditional architecture 
(organizational structure) from the one they initially experienced? 

More 1 2 3 4 5 6 7 More 

Traditional Nontraditional 



Comments: 
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A2C2 EXPERIMENT 

PLANNING ORGANIZER AND PRODUCTS BOOKLET 



Team ID: Planning Session: Date: 

Record the names of the four team members and the positions they played below: 

1. 3. 

2. 4. 

WHEN DOING YOUR PLANNING: BE FOCUSED — BE BOLD — BE DECISIVE 

You are free to: alter the authority structure (who reports to whom), alter the 
communications structure (who can speak to whom), reorganize the resources (assets) among the 
nodes (i.e. positions), and change the tasks a node or position is to perform. In shortchange the 
architecture (organizational structure). However, the number of nodes or positions is fixed at 
six (6) and the amount of resources are fixed. 

The purpose of the forms in this booklet is two-fold: 

• To help you replan the mission given the event and modify the existing 
organization and architecture, if you so desire. 

• To record the different planning products for analysis'. 

As a team you are asked to: 

• Provide a brief situation assessment. 

• Write a brief mission statement. 

• Provide diagrams of the authority and communication structure (architecture). 

• List the new tasks created by the event (if any) and tasks from the original mission 
that must be altered or reassigned. You are also asked to map resources against the 
tasks, state who will perform the tasks, sequence the tasks and estimate how long 
it will take to perform each task. 

• Provide a synchronization and coordination chart indicating the synchronization 
among the tasks. 

We strongly request that you perform each of the tasks listed above as you go through the 
planning and designing process and not wait until the end of the session. The tasks are designed 
to give structure to the planning and designing process and to help you organize your efforts. We 
also recommend that you do the tasks roughly in the order they are listed, but we understand that 
there might be some iterations back and forth between tasks. 



159 



SITUATION ASSESSMENT 



Carefully consider the event and the initial mission. What has happened? What do you 
know? Prepare a situation assessment brief in 50 or fewer words and write itin the space 
provided below. 
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MISSION STATEMENT 



After you and your team have come to an understanding of the tactical situation, prepare a 
mission statement of 100 or fewer words that would be suitable to brief a commanding officer. 
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ARCHITECTURE: AUTHORITY 



Please construct what you would consider the most appropriate command architecture for 
dealing with the event. This should be done in the form of a wire diagram as shown in the 
example below. 



Example Architecture 



Your Architecture Chart Below 
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ARCHITECTURE: COMMUNICATION 



Redraw your command architecture in the space below. On this diagram, include the 
communications links that each node is allowed to use. For example, draw lines from each to the 
other nodes with whom they can communicate. 



Indicate (by using double lines) which communications links are most crucial. 



Who will be talking to whom the most? 
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TASK GRAPH 



The following form provides a framework that you can use to organize information about 
the tasks your team must perform in this trial. That is, any new tasks created by the event, plus 
any tasks from the original mission that must be altered or reassigned. Please list the tasks you 
need to perform, which team position or positions are responsible (using the same position 
designations used in the authority diagram) for performing each task, and the resources necessary 
to accomplish each task. Also, indicate the time sequence the tasks must be performed in by 
writing a “1" in the “sequence” column next to all tasks that must be performed first, a “2” next 
to the tasks that must be performed second, etc. the duration is an estimate of how long the task 
will take to complete. Please give a real-time estimate of the duration. By “real-time”, we mean 
the best estimate of time needed to accomplish a task in the real world (not the simulated world 
of DDD). 



Sequence 


Tasks to perform 


Who will perform 
task 


Necessary resources 


Duration 
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Sequence 


Tasks to perform 


Who will perform 
task 


Necessary resources 


Duration 
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SYNCHRONIZATION AND COORDINATION CHART FOR TASKS TO COMPLETE 

THE MISSION 



As a team, prepare a synchronization chart either graphical or written (or a PERT chart) 
of all the tasks that are necessary to perform the mission successfully. The figure is an 
example of a graphical chart. Tasks that must be performed synchronously should be 
depicted at the same level or tier as Tasks 2a and 2b of the example. If two or more nodes 
must coordinate to accomplish a task, indicate this by writing the coordinating nodes in 
the task bubble, as in Task 3 of the example. 




Please sketch or write out vour 
synchronization and coordination 
chart below: 



Who will be coordinating the most with whom? What Tasks will require the most coordination? 
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